MASSACHUSETTS INSTITUTE OF TECHNOLOGY 
ARTIFICIAL INTELLIGENCE LABORATORY 

j\.I. Memo No. 1083 December 1989 

Optimization of Series Expressions: 

Part II: Overview of the Theory and Implementation 

by 

Richard C. Waters 


Abstract 

The benefits of programming in a functional style are well known. In par¬ 
ticular, algorithms that are expressed as compositions of functions operating on 
sequences/vectors/streams of data elements are easier to understand and modify 
than equivalent algorithms expressed as loops. Unfortunately, this kind of expres¬ 
sion is not used anywhere near as often as it could be, for at least three reasons: (1) 
Most programmers are less familiar with this kind of expression than with loops; 
(2) Most programming languages provide poor support for this kind of expression; 
and (3) When support is provided, it is seldom efficient. 

In any programming language, the second and third problems can be largely 
solved by introducing a data type called series, a comprehensive set of procedures 
operating on series, and a preprocessor (or compiler extension) that automatically 
converts most series expressions into efficient loops. A set of restrictions specifies 
which series expressions can be optimized. If programmers stay within the limits 
imposed, they are guaranteed of high efficiency at all times. 

A Common Lisp macro package supporting series has been in use for some time. 
A prototype demonstrates that series can be straightforwardly supported in Pascal. 
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Sequence Expressions 

1. Sequence Expressions 

The mathematical term ‘sequence’ refers to a mapping from the non-negative integers 
(or some initial subset of them) to values. Under the name of sequences [5, 36], vectors [23, 
31, 32, 36], lists [36], streams [6, 19, 25, 30], sets [35], generators [18, 48], and flows [34]’ 
^lata structures providing complete (or partial) support for mathematical sequences are 
[ubiquitous in programming. 

The most common use for sequence data structures is as mutable aggregate storage. 
Essentially every programming language provides operations for accessing and altering 
the elements of at least one such structure. 

Sequences have another use that is potentially just as important and yet is supported 
by only a few languages. Most algorithms that can be expressed as loops can also be 
(expressed as functional expressions manipulating sequences. For example, consider the 
[problem of computing the sum of the squares of the odd numbers in a file Data. This 
^an be done using a loop as shown in the following Pascal [24] program. 

type FileOfReal * file of Real; 

function FileSumLoop (Data: FileOfReal): Real; 

var Sum: Real; 
begin 

Reset(Data); 

Sum := 0; 

while not eof(Data) do 
begin 

If Odd(Dataj) then Sum := Sum+Sqr(Data|); 

Get(Data) 
end; 

FileSumLoop := Sum 
end 

Alternatively, the sum of the squares of the odd numbers in the file can be computed 
jising the sequence expression shown below. This expression assumes that four subrou¬ 
tines have been previously defined: CollectSum computes the sum of the elements of a 
1 ie quence; MapFn computes a sequence from a sequence by applying the indicated function 
jo each element of the input; Chooself selects the elements of a sequence that satisfy a 
predicate; and ScanFile creates a sequence of the values in a file. 

function FileSum (Data: FileOfReal): Real; 
begin 

FileSum := CollectSum(MapFn(Sqr, Chooself(Odd, ScanFile(Data)))) 
end 

For those who are not accustomed to functional programming, the greater familiar¬ 
ity of the program FileSumLoop may make it appear preferable. However, the program 
FileSum has two important advantages. First, the patterns of computation that are mixed 
together in the loop in FileSumLoop are pulled apart. Second, each of these subcompu¬ 
tations is distilled into a subroutine. For example, the pattern of initializing a variable 
to 0 and then repetitively accumulating a result by addition is distilled into CollectSum. 
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Because the subcomputations are pulled apart, they can be understood in isolation. 
The: action of the expression as a whole is the composition of the actions of the sub- 
iputations. This makes FileSum more self-evidently correct than FileSumLoop. The 
fixation of the subcomputations also means that they can be altered in isolation. This 
makes FileSum easier to modify. The distillation of the sub computations into subrou¬ 
tines makes FileSum shorter and enhances the reusability of the sub computations. It also 
enhances reliability in two ways. Since the subcomputations are being explicitly reused 
instead of regenerated by the programmer from memory, there is less chance of error. In 
addition, since each subroutine can be reused many times, it is practical to work very 
hard to ensure that the algorithm used in the subroutine is robust. 

Mnfortunately, there are two problems that inhibit most programmers from writing 
programs like FileSum. First, most programming languages provide very few predefined 
gedures that operate on sequences as aggregates, rather than merely operating on their 
ind vidual elements. Second, even in languages such as APL and Common Lisp, where 
a wide range of sequence operations are available, sequence expressions are typically so 
ineilicient (2 to 10 times slower than equivalent loops), that programmers are forced to 
loops whenever efficiency matters. 

[The primary source of inefficiency when evaluating sequence expressions is the phys- 
creation of intermediate sequence structures. This requires a significant amount of 


space overhead (for storing elements) and time overhead (for accessing elements and pag- 


The key to solving the efficiency problem is the realization that it is often possible to 


transform sequence expressions into a form where the creation of intermediate sequence 
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ctures is eliminated. For example, it is straightforward to transform the expression 
in tfileSum into the loop in FileSumLoop. 

A transformational approach to the efficient evaluation of sequence expressions has 
beet used in a number of contexts. For example, it is used by optimizing APL compil¬ 
ers [11, 21], Wadler’s Listless Transformer [38, 39] which can improving the efficiency of 
programs written in a Lisp-like language, and Bellegarde’s transformation system [7, 8] 
whiph can improve the efficiency of programs written in the functional programming lan¬ 
guage FP [5]. In addition, Goldberg and Paige [17] have shown that the transformational 
approach can be used to improve the efficiency of data base queries. 

Jnfortunately, it is not possible to completely transform every sequence expression 
an efficient loop. There are two basic ways to deal with this problem. First, one 
hide the issue from the programmer and simply transform what can be transformed. 
Second, one can develop a set of restrictions defining what can be transformed and 

communicate with the programmer about the transformability of individual sequence 
exp] ess ions. 

.he hidden approach, which is followed by all the systems above, has the advantage 
programmers can benefit from increased efficiency in some situations without having 
ink about efficiency in any situation. However, it makes it difficult for programmers 
ink about efficiency when they want to, because they have no way of knowing for sure 
her a given sequence expression will be completely transformed. This is significant, 
beejuse sequence expressions typically remain quite inefficient if any part of them fails to’ 
be transformed. In addition, quite simple changes in an algorithm often suffice to change 
an untransformable expression into a transformable one. As a result, it is not really a 
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favor to hide the issue of transformability from programmers. 

The most important contribution of the research reported here is a set of restric¬ 
tions that can serve as a basis for the communicative approach to the transformation 
bf sequence expressions into loops. As discussed in Section 2, these restrictions identify 
a class of optimizable sequence expressions that can always be completely transformed. 
The restrictions are novel in two ways. First, they are explicit. While every system that 
Optimizes sequence expressions implicitly embodies some set of restrictions, the restric¬ 
tions used are not explicit except in the work of Wadler [40]. Second, the restrictions in 
Section 2 are less strict than most other sets of restrictions. In particular, they are much 
less strict than Wadler’s restrictions. 

Sections 4-6 show how the communicative approach can be used to add comprehensive 
^nd efficient support for sequence expressions into any given programming language. This 
Js done by adding a new sequence data type called series and a preprocessor that can 
transform optimizable series expressions into loops. The support for series utilizes the 
joptimizability restrictions in two ways. One of the key restrictions is enforced by selecting 
jthe set of series operations so that the restriction cannot be violated. The rest of the 
Restrictions are explicitly checked by the preprocessor. Non-optimizable expressions are 
flagged with warning messages and left unoptimized. If users take the time to make 
pach series expression optimizable, they can have complete confidence that every series 
Expression is efficient. This is facilitated by the fact that simple series expressions that 
Enly use each series once can always be optimized. 

Section 3 presents the series data type and a broad suite of associated functions. 
Currently, the most comprehensive support for series is in Common Lisp. This imple¬ 
mentation [46, 47] is presented in Section 4, along with an extended Lisp example showing 

I low series expressions can be used. A prototype implementation [28, 45] shows that series 
expressions can also be added into Pascal. This implementation is presented in Section 5, 
ilong with an extended Pascal example of how series expressions can be used. Readers 
ire encouraged to focus on whichever of Sections 4 and 5 discusses the most familiar 
anguage. 

Section 6 presents the algorithms used to transform optimizable series expressions 
into loops. Section 7 concludes by comparing series expressions with related concepts. 
The comparison includes both other implementations of sequences and other approaches 
Ro expressing loops in ways that are easy to understand and modify. 

Getting Rid of Loops 

To fully appreciate the practical impact of series expressions in general and optimiz- 
■jble ones in particular, one must return to the perspective of sequence expressions as a 
rotational variant for loops. The program FileSum is an example based on the Pascal 
implementation of series. The series expression in it is optimizable and is transformed 
into a loop essentially identical to the one in FileSumLoop. As a result, it is not merely 
1 he case that FileSumLoop and FileSum compute the same result using the same abstract 
algorithm; the two programs denote exactly the same detailed computation. Using the 
Expression in FileSum, one gains the advantages of functional form without paying any 
price in terms of efficiency or anything else, because there is no change in anything other 
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thap the notation. 

The value of optimizable series expressions as an alternate notation for loops is directly 
ted to the percentage of loops that can be profitably replaced by them. Any loop 
be expressed as an optimizable series expression by converting the sub computations 
in it into series operations and composing them together. (At worst, the entire 
becomes a single series operation.) The value of doing this depends on how many 
ments the loop can be decomposed into and how many of these fragments correspond 
familiar computations. In general, the change is advantageous as long as there is at 
one familiar fragment, because at the least, there is value in separating the familiar 
the unfamiliar. 

JAn informal study [41] revealed that 80% of the loops programmers typically write 
constructed solely by combining just a few dozen familiar looping fragments. (A 
ewhat similar study is reported in [15].) Experience with the Lisp implementation of 
0 s expressions indicates that at least 95% of loops contain some familiar computation. 
p n this, the practical benefit of optimizable series expressions can be summarized as 
follows: 

Optimizable series expressions are to loops 
as structured control constructs are to gotos. 

Structured control constructs (if.. .then... else, case, while... do, repeat.. .until) 
not capable of expressing anything that cannot be expressed as gotos. In addition, 
e are probably a few algorithms for which the use of gotos is preferable. Nevertheless, 
a||most every situation, structured control constructs are much better to use than gotos. 
y are better, not because they allow more algorithms to be expressed, but because 
allow the same algorithms to be expressed in a way that is much easier to understand 
modify. 

ptimizable series expressions have the exact same advantage. They do not allow 
jrithms to be expressed that cannot be expressed as loops. However, they allow 
rithms to be expressed in a much better way. The only place where the analogy 
structured control constructs breaks down is that while one can argue that gotos 
[never needed, there are definitely some algorithms that can be expressed better as 
s than as optimizable series expressions. 

jjVt the current time, most programs contain one or more loops and most of the inter- 
g computation in these programs occurs in these loops. This is quite unfortunate, 
loops are generally acknowledged to be one of the hardest things to understand in 
program. If optimizable series expressions were used whenever possible, most pro- 
would not contain any loops. This would be a major step forward in conciseness, 
ac|ability, verifiability, and maintainability. 
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Optimizable Sequence Expressions 

2. Optimizable Sequence Expressions 

As noted above, the primary source of inefficiency when evaluating sequence expres¬ 
sions is the creation of intermediate sequence structures. There are two aspects to this. 
First, a subexpression may compute a sequence only part of which is used by the rest 
bf the expression. Second, even when all the elements are used, a significant amount 
of space and time overhead is required to construct physical data structures containing 
them. 

The first problem can be overcome by using lazy evaluation [16] to ensure that se¬ 
quence elements are not computed until they are actually used. (This also makes it easy 
^o support unbounded sequences.) However, lazy evaluation does little to assist with the 
(second problem. In particular, in simple situations where the sequence elements are all 
jused, lazy evaluation wastes time and does not save any space. Although the same ele¬ 
ments are computed, time is wasted, because coordination overhead is required to decide 
When to compute the elements. The same space is used, because each element has to 
^e stored after it is computed. (Otherwise, a later reuse of an element would require 
jrecomputation.) 

Both of the problems above can be solved by pipelining the evaluation of sequence ex¬ 
pressions. When this is possible, elements are computed on demand without coordination 
bverhead and do not have to be stored. 

(Definition 1 (Pipelined) The evaluation of a sequence expression E is pipelined if the 
Evaluation proceeds in such a way that the following conditions hold for every sequence S 
qomputed by any part of E. First, each element of S is computed at most once. Second, 
When an element is computed, it is used wherever it needs to be used, and then discarded 
before any other element of S is computed. 

The primary implication of the definition above is that, while some of the procedures 
balled by E may buffer sequence elements within themselves, no additional buffering is 
Required when evaluating E. Each sequence is transmitted between the procedure that 
creates it and the procedures that use it, one element at a time. 

When compile-time pipelining is possible, a sequence expression can be evaluated as 
efficiently as a loop. Unfortunately, pipelining is not always possible. Any system that 
does pipelining can only do so for a restricted class of sequence expressions. Whatever 
jhe system, it is valuable for these restrictions to be made explicit. If in addition, the 
programmer is given feedback about which expressions fail to meet the restrictions, two 
advantages can be obtained. First, the programmer is given a clear picture of which 
Expressions are efficient and which are not. Second, the programmer has the opportunity 
ijo change inefficient expressions so that they can be pipelined. 

It would be nice to have a set of necessary and sufficient restrictions that specifies 
Exactly which sequence expressions can be pipelined. However, there are a number of 
reasons why a somewhat stricter set of restrictions are of greater pragmatic benefit. First, 
i;he restrictions must be associated with practical algorithms that can check whether the 
restrictions hold and can perform the pipelining. Second, the restrictions must be simple 

Enough to understand that programmers can succeed in fixing expressions that violate 
them. 




6 


Optimizable Sequence Expressions 

The primary contribution of the work presented here is a set of five restrictions that 
satisfy the subsidiary goals above without being excessively strict. These restrictions 
define a class of optimizable sequence expressions. It can be shown that every optimizable 
seqjience expression can be pipelined at compile time by transforming it into a loop, using 
the algorithms in Section 6. 

Definition 2 (Optimizable Sequence Expression) An optimizable sequence ex¬ 
pression is a sequence expression that satisfies the following restrictions: 

1) Optimizable sequence expressions must be statically analyzable. 

2) Optimizable sequence expressions must be straight-line computations. 

3) Procedures called by optimizable sequence expressions must be preorder. 

4) Intermediate values in optimizable sequence expressions must be sequences. 

) Every non-directed data flow cycle in an optimizable sequence expression 
must be on-line. 

|The restrictions in Definition 2 can be divided into three groups. A restriction anal¬ 
ogous to the first one is required for any optimization that is to be applied at compile 
timfe as opposed to run time. The second restriction greatly simplifies the algorithms 
in Section 6, but is undoubtedly stronger than necessary. It is hoped that it will be 

weakened in the future. The remaining three restrictions are the theoretical heart of the 
matter. 

In this section, programs are discussed from the point of view of data and control flow 
graphs rather than program text. In this representation, procedure calls and data literals 
are represented by nodes. The nodes have labeled ports corresponding to data inputs 
and outputs. There are no limits on the numbers of inputs or outputs. Data flow is 
represented by directed arcs connecting output ports to input ports. A given output can 
be <|onnected to several inputs. Control flow is modelled by additional arcs connecting 
special control inputs and outputs. In the context of these graphs, the term sequence 
expression is defined as follows. 

Dei^nition 3 (Sequence Expression) A sequence procedure is a procedure that 
consumes or produces a sequence. A sequence data flow is a data flow arc that transmits 
a sequence. A sequence subexpression is a (not necessarily proper) subset of the nodes 
in a data and control flow graph that can be built up through repetitive application of 
the following two rules. Each node corresponding to a sequence procedure call or literal 
sequence is a sequence subexpression. If there is a sequence data how from a node in a 
sequence subexpression X to a node in another sequence subexpression Y, then X U Y 
is a sequence subexpression. A sequence expression is a sequence subexpression that is 
not a proper subset of any other sequence subexpression. 

The Static Analyzability Restriction 

As with most other optimization processes, a sequence expression cannot be pipelined 
at compile time, unless it can be determined at compile time exactly what computation 
is being performed. To make sure that this will be possible, it is required that every use 
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of a sequence procedure in an optimizable sequence expression be an explicit call on a 
predefined sequence procedure. This ensures that it will always be clear exactly what 
sequence computation is being performed. 

Similarly, it is required that every sequence value come directly from a sequence 
procedure call. This ensures that it will always be clear exactly how the sequence is 
being computed. Unfortunately, this also implies that a sequence cannot be stored in 
any kind of data structure. This is undoubtedly somewhat stronger than necessary. 

Arbitrary storage of sequences in data structures is bound to block compile-time 
pipelining. However, certain limited cases could be allowed. For instance, one can some¬ 
times determine how a sequence contained in another sequence is being computed. The 

f racticality of this has been demonstrated by compilers for APL [111, Hibol [341 and 
lodel [32]. 


The Straight-Line Restriction 

I In the interest of simplicity, optimizable sequence expressions are required to be 
traight-line computations, not subject to any conditional or looping control flow. That 
s to say, it must be the case that whenever a sequence expression is evaluated, every 
>rocedure call in it is evaluated exactly once. 

! While it is likely that looping control flow in sequence expressions must be prohibited, 
simple conditional control flow could probably be allowed. However, this would compli¬ 
cate pipelining in a number of ways and much of what can be done using conditional 
pontrol flow can be done using operations like Chooself instead. 

I The fact that sequence expressions are straight-line computations means that they 
tan be pipelined without worrying about control flow. As a result, control flow is not 
jnentioned in the rest of this discussion. 


The Preorder Restriction 

Suppose that a procedure call 7F uses a sequence computed by another procedure 
call Q. For the computation of these two calls to be pipelined, two conditions must be 
i atisfied. First, it must be the case that the sequence elements are created and consumed 
one at a time. Second, the elements must be consumed in the same order they are 
created. A good way to ensure that this will always be the case is to pick some fixed 
order and require that every sequence procedure process every sequence one element at 

a time in that order. Given a desire to support unbounded sequences, a good order to 
pick is preorder. 

Definition 4 (Preorder) A sequence procedure is preorder if it processes the elements 

dfeach of its sequence inputs and outputs one at a time in ascending order starting with 
me first element. 


w 


d 


In this paper, the word ‘function’ is reserved for referring to mathematical functions, 
hile the word ‘procedure’ is used to refer to the implementation of a function in a 
rogramming language. With that in mind, note that the definition above applies to 
rocedures, not functions. It is a property of the way a computation is performed, not 
r ma thematical relationship between the input and the output. Any mathematical 
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sequence function can be implemented as a preorder procedure. At worst, one can simply 
read the input elements into a buffer in preorder, compute the result, and then write the 
elei nents of the result in preorder. 

A property that does apply to mathematical functions is the amount of internal 
buf ering that is required when implementing the function as a preorder procedure. For¬ 
tunately, most sequence functions can be implemented as preorder procedures that do 
not require internal buffering of input or output elements. For instance, the procedure 
MapFn operates as follows: it reads one element of each input sequence, applies the in¬ 
dicated function to them, writes the resulting output element, and then goes on to the 
nex t group of input elements. 

The only common functions where internal buffering is required are ones that re¬ 
arrange the input elements (e.g., reversal, rotation, and sorting). In same cases this 
buffering is solely due to the needs of preorder processing. For instance, while preorder 
reversal requires the entire input to be read before the first output element can be pro- 
duced, some non-preorder implementations require no buffering. In other cases (e.g., 
sorting) the buffering is required no matter how the operation is implemented. 

The goal of pipelining is the elimination of the external buffering of elements between 
pro uedure calls. The algorithms in Section 6 are applicable no matter how much internal 
buffering the individual procedures use. As a result, the restrictions in Definition 2 do 

not place any limits on internal buffering. (This issue is discussed further at the end of 
this section.) 

Nevertheless, using large internal buffers clearly violates the spirit of what pipelining 
is tijying to achieve. It is of no benefit to eliminate external buffering if this is replaced 
by internal buffering. Therefore, in the interest of overall efficiency, the functions oper¬ 
ating on series (see Section 3) are limited to ones that can be implemented as preorder 
procedures without internal buffering of sequence elements. 

The Sequence Intermediate Value Restriction 

Wen it a sequence expression satisfies the three restrictions above, it may still not 
be j >ossible to pipeline its evaluation. The problem is that if a sequence is used in two 
places, the two uses may place incompatible constraints on the times at which sequence 
elements should be computed. 

f The following program shows an expression in which this problem arises. (This pro¬ 
gram, and the others below, are based on the Pascal implementation of series, see Sec¬ 
tion 5.) The sequence expression in NormalizedMax creates a sequence X of the numbers 
in a file Data. It then creates a normalized sequence by dividing each number by the 
sum of the numbers. Finally, the procedure returns the maximum of the normalized 
elements. (The procedure Series creates a sequence indefinitely repeating the value of 
its argument. The call on MapFn divides each element of X by this value.) 

function NormalizedMax (Data: FileOfReal): Real; 

var X: series of Real; 
begin 

X := ScanFile(Data); 

NormalizedMax := CollectMax(MapFn(/, X, Series(CollectSum(X)))) 
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The two uses of X place contradictory constraints on the way pipelined evaluation 
Jnust proceed. The procedure CollectSum requires all the elements of X to be produced 
before the sum can be returned and Series requires that its input be available before it 
can start producing its output. However, MapFn requires that the first element of X be 
available at the same time as the first element of the output of Series. For pipelining 
to work, this implies that the first element of the output of Series (and therefore the 
output of CollectSum) must be available before the second element of X is computed. 
Unfortunately, if X contains more than one element, this is impossible. 

The essence of the inconsistency above is the cycle of constraints used in the argument. 
This in turn stems from a non-directed cycle in the data flow graph underlying the 
expression. Figure 2.1 shows the nodes in the sequence expression in NormalizedMax 
and the data flow between them. The nodes are represented by boxes and data flow is 
represented by arrows. Simple arrows indicate the flow of sequences and cross hatched 
arrows indicate the flow of other values. 



Figure 2.1: The sequence expression in NormalizedMax. 

From the point of view of Figure 2.1, the problem in Normal izedMax can be summa¬ 
rized by noting that the non-directed data flow cycle has two conflicting parts. In the 
ipper part, pipelining requires that each sequence element be used as soon as it is com¬ 
muted. In the lower part, the non-sequence data flow forces a delay—all of the elements 
at the left end of the lower part have to be available before any of the elements at the 
right end can be produced. If the upper part also contained a non-sequence data flow, 
'hen the delays on the two parts would balance. However, if there was a non-sequence 
lata flow in the upper part, the expression would be broken into two separate sequence 
ixpressions: one on the left and one on the right. 

Based on Definition 3, it can be shown that whenever a non-sequence value created by 
i node in a sequence expression is used by another node (either directly as in Figure 2.1 
' >r via a chain of computation) the expression will be associated with a non-directed cycle 
ike the one in Figure 2.1. To prevent this problem, it is required that intermediate values 
:n optimizable sequence expressions must be sequences. 

This restriction places significant limits on the qualitative character of optimizable 
; equence expressions. In particular, they all have the general form of creating some 
humber of sequences, computing various intermediate sequences, and then computing one 
(>r more non-sequence results. A non-sequence value cannot be used in the intermediate 
Computation unless it is the output of a disjoint expression. 
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The On-Line Cycle Restriction 

The last situation that can block pipelining is illustrated in the program OddSum 
belbw. This program creates a sequence X of the numbers in a file. It then selects the 
odc| elements of X and multiplies the ith odd element of X by the «th element of X. Finally, 
it stuns the resulting products. 

function OddSum (Data: FileOfReal): Real; 

var X: series of Real; 
begin 

X := ScanFile(Data); 

OddSum := CollectSum(MapFn(*, X, Chooself(Odd, X))) 
end 

As in the program NormalizedMax, the two uses of X place contradictory constraints 
on the way pipelined evaluation must proceed. The key problem is that Chooself is 
inherently unsynchronized in the way it operates. In this example, it produces output 
elements only when it reads odd input elements. However, MapFn requires that the ith 
element of X be available at the same time as the z'th element of the output of Chooself. 
For pipelining to work, this implies that the ith element of the output of Chooself must 
be available at the same time that Chooself reads the «th element of X. Unfortunately, if 
any of the first i elements of X are even, this is impossible. 

\s shown in Figure 2.2, the problem in OddSum is fundamentally much the same as the 
problem in Normal izedMax. In particular, it also stems from a non-directed cycle in the 
underlying data flow graph. Like the non-sequence data flow in Figure 2.1, the Chooself 
in Figure 2.2 introduces a delay that is not matched in the other part of the cycle. This 
dels y depends on the input data, but may be arbitrarily large. 



Figure 2.2: The sequence expression in OddSum. 


I n contrast to OddSum, consider the program CosSum below, which is identical except 
that Chooself is replaced by MapFn of Cos. A sum is computed of each element of X 
muljiplied by its cosine. 

j 

function CosSum (Data: FileOfReal): Real; 

var X: series of Real; 
begin 

X := ScanFile(Data); 

CosSum := CollectSum(MapFn(*, X, MapFn(Cos, X))) 
end 
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Even though CosSum has exactly the same data flow graph as OddSum (with Chooself 
Replaced by MapFn of Cos), CosSum can be pipelined without difficulty. The reason is that 
the MapFn of Cos produces an output element every time it reads an input element. There¬ 
fore, there is no problem synchronizing the arrival of the elements of the two sequence 
inputs of the MapFn of *. 

The comparison of OddSum and CosSum shows that pipelining is blocked in OddSum by 
the delay introduced by Chooself, rather than by the mere existence of a non-directed 
data flow cycle. To develop a good restriction that rules out this problem, one has to 
develop a vocabulary for talking about where delays are introduced. 

Definition 5 (On-Line and Off-Line) An input or output port of a sequence pro¬ 
cedure is on-line if and only if it operates in lock step with all the other on-line ports 
jof the procedure as follows: The initial element of each on-line input is read, then the 
initial element of each on-line output is written, then the second element of each on-line 
fnput is read, then the second element of each on-line output is written, and so on. If 
jail of the sequence ports of a procedure are on-line, the procedure as a whole is on-line. 
|A non-directed cycle of data flow is on-line if every port it passes through is on-line. A 
non-directed cycle passes through an input or output port of a procedure call if and only 
if exactly one data flow arc in the cycle touches the port. (For example, the cycle in 
Figure 2.2 passes through every port it touches except for the output of ScanFile.) If a 
port, procedure, or data flow cycle is not on-line, it is off-line. 


Definition 5 extends the standard definition of the term ‘on-line’ [1, 22] so that it 
Applies to individual ports as well as whole procedures. Like Definition 4, Definition 5 
applies to procedures, rather than functions. While, some mathematical functions (e.g., 
phoosing elements from a sequence) cannot be implemented in an on-line fashion, many 
can. For example, since the 1th element of the result of mapping a function is computed 
;|olely from the 1th elements of the inputs, it is easy for MapFn to be on-line. 

Returning to the issue of pipelining, it can be shown that if a non-directed data flow 
l^ycle in an optimizable sequence expression is on-line, the lock step processing of the 

I iorts involved guarantees that there will not be any conflicts between the constraints 
ssociated with the cycle. If every non-directed cycle in an expression is on-line, the 
valuation of the expression can be pipelined using the following divide and conquer 
pproach. 

It can be shown that when a sequence expression in which every non-directed data 
ow cycle is on-line contains an off-line port, it is always possible to divide the expression 
to two non-overlapping subexpressions so that all data flow between the subexpressions 
riginates (or terminates) on the off-line port in question. The expression as a whole can 
e pipelined by pipelining the evaluation of the two subexpressions separately and using 
simplified form of lazy evaluation to interleave the evaluation of the subexpressions in a 
ipelined fashion. The lazy evaluation is simplified because the method for determining 
rhich subexpression to evaluate when is very simple. The first subexpression needs to 
e evaluated when the second subexpression needs to read a new value computed by it. 
Once partitioning based on off-line ports has been applied as many times as possible, 
dne is left with subexpressions where every data flow connects on-line ports. In such a 
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subexpression, pipelining can be achieved by simply evaluating every procedure call in 
loclt step, one element at a time. 

The limits imposed by the on-line cycle restriction are softened by the fact that a 
wide range of mathematical sequence functions can be implemented in an on-line way. 
For instance, any preorder procedure that has only one sequence port is trivially on-line. 
Beyond this, most of the functions in Section 3 can be implemented as on-line procedures. 

Obeying the Restrictions 

n the current implementations of series (see the discussion in the following sections), 
the preorder restriction is implicitly enforced by ensuring that every predefined series 
procedure is preorder and not providing any means for defining series procedures that 
are not preorder. (Note that the composition of two preorder procedures is preorder.) 

The other four restrictions are explicitly checked. Whenever an expression satisfies 
thes e restrictions, the algorithms in Section 6 are used to transform the expression into 
an efficient loop. When they are not satisfied, a warning is issued. In the Pascal im¬ 
plementation, these warnings are fatal errors. However, in the Lisp implementation, the 
exp] essions are simply left as is and evaluated/compiled without optimization. 

The best approach for programmers to take is to write expressions without worrying 
abo it the restrictions and then fix the expressions in the event that a problem is reported. 
The virtues of this approach are enhanced by the fact that simple expressions are very 
unli cely to violate any of the restrictions. In particular, it can be shown that if every 
seqr ence procedure in an expression has only one output and sequence outputs are not 
stored in variables, then the sequence intermediate value and on-line cycle restrictions 
cannot be violated. 

k 'inffiarly, it can be shown that violations of the sequence intermediate value and on¬ 
line cycle restrictions can always be fixed using code copying to break the expression in 
two or to break the offending cycle. For instance, the program NormalizedMax can be 
broi ght into compliance with the sequence intermediate value restriction by duplicating 
the call on ScanFile. This breaks the sequence expression into two separate sequence 
expi essions that each satisfy the sequence intermediate value restriction. 

function NormalizedMaxA (Data: FileOfReal): Real; 

var Sum: Real; 
begin 

Sum := CollectSum(ScanFile(Data)); 

NormalizedMax := CollectMax(MapFn(/, ScanFile(Data), Series(Sum))) 
end 

I k would be possible to automatically introduce code copying to resolve conflicts with 
the ijequence intermediate value and on-line cycle restrictions. However, this can lead to 
significant inefficiencies. It is better to leave it up to the programmer to figure out how to 
fix conflicts. For example, the procedure NormalizedMax can be brought into compliance 
mor<: efficiently, by realizing that the operations of computing the maximum and dividing 
by t]|ie sum commute. 
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function NormalizedMaxB (Data: FileOfReal): Real; 

var X: series of Real; 
begin 

X :* ScanFile(Data); 

NormalizedMax := CollectMax(X)/CollectSum(X) 
end 

This example brings up an important secondary goal underlying the restrictions pre¬ 
sented here. This goal is to make it easy for programmers to reliably tell which expressions 
are efficient and which are not. It would be better to make every expression efficient. 
However, given that this is not possible, programmers need accurate information in order 
|to decide what to do. 

Other Approaches to Restrictions 

The optimizability restrictions presented above are the result of research going back 
(twelve years. The basic concept of representing common looping subcomputations as op¬ 
erations on sequences is descended from ideas developed in the Programmers Apprentice 
project [33, 41]. The first attempt to state a formal set of restrictions appears in [42, 43]. 
p set of restrictions intermediate between the initial ones and the ones presented above 
hppear in [44]. 

Optimizability restrictions are implicit in all the work on sequence expression opti¬ 
mizers. However, these restrictions are typically implicit in the way the optimizers work, 

father than being explicitly stated. The only other research featuring explicit restrictions 
s that of Wadler [40]. 

The key difference between Wadler s restrictions and the ones presented here is that 
le assumes that procedures can only have one output and only considers the situation 
jvhere two procedures are composed together. This can be straightforwardly generalized 
o expressions that are tree-like in form—i.e., ones where the output of each function is 
only used once. However, it is not applicable to more complex situations. 

Wadler’s implicit requirement that expressions be trees rules out non-directed data 
low cycles. This obviates the need for anything like the sequence intermediate value or 
' >n-line cycle restrictions. However, it is unreasonably limiting. Since it is often possible 
i o pipeline the evaluation of an expression even though it contains non-directed cycles of 
data flow, it is unreasonable (both from the point of view of readability and efficiency) 

1 o require that an intermediate value that is used in n places must always be computed 
n times. 

The restriction that Wadler explicitly states (i.e., that procedures must be preorder 
\ istless) is basically equivalent to the preorder restriction stated here, except that it also 
limits the storage used, as discussed below. (Wadler’s definition of the term preorder is 
different from the one used here.) 

Another significant difference between Wadler’s work and the work presented here is 
that he approaches the problem of efficiency from a different direction. Rather than con¬ 
sidering pipelining directly, he focuses on the amount of storage required when evaluating 
c(n expression. He requires that preorder listless procedures evaluate using a bounded 
ctmount of storage (over and above the storage required for the inputs and outputs them¬ 
selves) and shows that the composition of two such functions can be evaluated using a 
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boi nded amount of storage (over and above the storage required for the net inputs and 
outputs of the composition). 

It can be shown that when all the procedures called by an optimizable sequence ex- 
pre jsion use bounded storage, the pipelined evaluation of the expression will use bounded 
stOj cige. However, it was decided not to introduce a restriction limiting sequence proce- 
dui ss to bounded storage for three reasons. First, such a restriction has nothing to do 
wit 1 pipeline per se. Pipelining can be applied just the same no matter how much storage 
the individual procedures use. The key thing is that pipelining allows the storage require¬ 
ments of an expression to be the sum of the storage requirements of the procedures called 
by t. Second, when considering individual sequence procedures a requirement that they 
use bounded storage is too weak to be useful. As discussed in the section on the preorder 
rest riction, one certainly does not want unbounded storage to be used to store input or 
output elements. (However, what if it is used for some other purpose?) In addition, large 
fixed storage needs are just as much of a practical problem as unbounded ones. What 
is r ;ally needed is for the implementor of the procedure to make a good faith effort to 
use as little storage as possible. Third, such a restriction cannot be usefully supported, 
beciuse there is no practical way to determine whether a user-defined sequence procedure 
requires unbounded storage. 

\ final difference between Wadler’s work and the work presented here is that Wadler 
chone to apply his restrictions to a pre-existing data type (lists). In the approach taken 
here, a new data type (series) is developed for three reasons. First, since lists cannot 
repi esented unbounded sequences, focusing on lists unduly limits the kind of procedures 
thal can be expressed. Second, lists (and vectors) have evolved a style of use and a 
suit 3 of associated operations that are appropriate for that use. These work well for 
thei r intended use, but are not as useful as they could be from the perspective of writing 
efficient sequence expressions. Developing a new data type makes it possible to create a 
new suite of operations that is more appropriate for this purpose. Third, an important 
parlj of the approach being advocated here is the error messages that report unoptimizable 
series expressions. These are important if programmers are to achieve efficiency. However, 
the] would be irritating and counterproductive if they were constantly being reported 
for ist expressions that were not intended to be optimizable. By adding a series data 
fyP <: > programmers can benefit from the restrictions when they choose to follow them, 
witljout being prevented from using lists, vectors, and streams in standard ways. 
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S. Series Expressions 

Vectors, lists, and other such data structures differ in how closely they model the 
fnathematical concept of a sequence and in the range of associated operations. The 
Series data type embodies a set of design decisions that combine full support for the 
mathematical concept of a sequence, a wide range of operations, and high efficiency. As 
llustrated in the next two sections, support for series can be straightforwardly added 
to any programming language. High efficiency is obtained by using a preprocessor or 
Compiler extension like the one presented in Section 6. 

Informally speaking, series are like vectors except that they can be unbounded in 

i ength. Formally, series are defined by the way they can be operated on. The remainder 
>f this section presents an illustrative selection of these operations as mathematical func- 
ions. (See [9] for an in depth discussion of the mathematical properties of many of these 
unctions when applied to finite sequences.) The next two sections present procedures 
Implementing these functions in specific programming languages. 

In the following, lowercase letters (x, y) denote arbitrary values, uppercase letters 

I R, S) denote series, and calligraphic letters (J 7 , V) denote functions and predicates. 
i addition, special notations are used to denote four of the most basic series functions, 
he construction function, which creates a series containing the indicated elements in 
le indicated order is denoted using angle brackets, i.e., (x, y, ..., z). The concatenating 
mction, which creates a series containing the elements of a series R followed by the 
ements of another series S is denoted using the operator “||”, i.e., R || S. The tail 
inction, which creates a series containing the elements of a non-empty series S after the 
rst one is denoted by drawing a line over the series, i.e., 5. The head function, which 
;turns the first element of a non-empty series is denoted by subscripting the series with 
Kero, i.e., S 0 . (For convenience, the series used as examples below contain numerical 
Elements. However, any kind of object can be used as a series element.) 

(6,7,8> || (9,10) = (6,7,8,9,10) 

(6,7,8) = (7,8) 

<6,7,8) 0 = 6 

(10, (4,5) 0 ,20) = (10,4,20) 

Series functions can be divided into three categories: scanners produce series without 
Consuming any, collectors compute non-series values from series, and transducers compute 
jeries from series. For instance, the head function is a collector and the concatenating 
“unction is a transducer. 

There are two kinds of scanners. Some scanners create a series of the elements in an 
tggregate data structure, for instance, a series of the nodes in a tree. Other scanners 
create a series based on some formula, for instance, the successive powers of some number. 
The Lisp implementation of series supports 15 scanners. However, one of these (scanning, 
;iee below) can be used to define all the rest. 

Scanning is a higher-order function—a function that takes functions as arguments. 
The first argument is an initial value 2 , which becomes the first element of the series 
•treated. The second argument is a stepping function J 7 , which is used to compute each 
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series element from the previous element. The third argument is a predicate V, which is 
used to determine where the series should end. The series created contains the elements 
2 , J r (z ), P(P(z)), and so on, up to but not including the first value satisfying V. If no 
valhe satisfies V , the series is unbounded in length. The example computes the powers 
of 2 that are less than 100 . 


scanning^, T, V) = 


= ( 0 
l <*> 


if V(z) 

|| scanning(^( 2 ), T , V) otherwise 


scanning(l, \x.x+x, A £.£> 100 ) = (1,2,4,8,16,32,64) 

There are also two kinds of collectors. Some collectors create an aggregate data 
stri cture containing the elements of a series, for instance, a hash table containing the 
series elements. Other collectors create a summary value computed by some formula 
fror i the elements of a series, for instance, their sum. The Lisp implementation of series 
sup :>orts 18 scanners. However, one of these (the higher-order series function collection 
shown below) can be used to define all the rest. 

Collection uses a binary function T to combine the elements of a series S together. 
The combination process begins with an initial value 2 . Typically, 2 is chosen to be a 
left identity of T. The example computes the sum of a series. 


collection( 2 :, T, S) = 


* if 5 = () 

collection(^( 2 :, So), T, S) otherwise 


collection( 0 , A xy.x+y, ( 1 , 2 , 3 )) = 6 

Transducers are more complex than scanners or collectors. In particular, there is no 
one transducer that serves as a basis for the rest. Nevertheless, four key higher-order 
trar sducers support wide classes of common transduction operations. 

Collecting is the same as collection except that it returns a series of partial results, 
rati er than just a final value. The length of the output is the same as the length of S. 
Thej example computes a series of partial sums. 

Collecting^, T, S) = / „ if 5 = () 

\ Sq)) || collecting (T(z, So), T, ~S) otherwise 

collecting(0, A xy . x+y, (1,2,3)) = (1,3,6) 

By far the most commonly used series function is mapping, which maps a function 
T over some number of series producing a series of the results. Each element of the 
output is computed by applying T to the corresponding elements of the inputs. The 
length of the output is the same as the length of the shortest input. The example adds 
the Corresponding elements in two series. 

f () if any S* = () 

mapping^, 5 1 , ..., S n ) = { (JF(S 0 \ ..., £%)) || . 

I --:_ i d T 7 r\ otherwise 


mapping^, S\ S n ) = j S"))J| 

(. mapping^, S\ . 

mapping(A xy . x+y, <1,2,3), <4,5, 6 ,7)) 


., 5") 

= (5,7,9) 
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Truncating cuts off a series by testing each element with a predicate and discarding 
kll the remaining elements as soon as an element satisfying the predicate is encountered. 
The example truncates a series at the first negative element. 


truncating^, S) = 


/ o 

{S 0 ) || truncating^, ~S) 


if S' = () or V(S 0 ) 
otherwise 


truncating(A x . #<0, (0,3,2,-7,1,-1)) = (0,3,2) 

Mingling combines two series into one under the control of a comparison predicate. 
The comparison is performed as indicated to ensure that the combination will be stable— 
f two elements are considered equal by the comparison predicate, the element from R 
vill precede the element from S in the result. The example shows the combination of 
;wo sorted series into a sorted result. 


mingling^, S', V) 


R 

S 

(Ro) II mingling(i?, S', V) 
(S 0 ) || mingling (R, S', V) 


if 5=() 
if i? = () 
if -P(S 0 , Ro) 
otherwise 


mingling«l,3,7), (2,4,5), Xxy.x<y) = (1,2, 3,4,5, 7) 


Choosing selects the elements of a series that satisfy a predicate. The example picks 
j>ut the negative elements of the input. 


<> 

choosing(“P, S') = (5 0 ) || choosing(P, S') 

k choosing(P, S) 

choosing(A x . :r<0, (0,3,2,—7,1,—1)) = 


if S' = () 
if V(S 0 ) 

otherwise 

(-7,-1) 


In addition to the higher-order transducers above, some specific transducers are im¬ 
portant as well. The function spreading is a quasi-inverse of choosing. Spreading takes a 
ijeries of non-negative integers R and a series of values S', and creates a series containing 
ijhe elements of S'. In the output, the elements of S are spread out by interspersing them 
fith copies of z. If the ith. element of R is n, then the zth element of S is preceded by 
T co P ies °f Taken together with the example above, the example below illustrates the 
ijelationship between choosing and spreading. 


spreading(P, 5, z) = < 


0 

(S 0 ) || spreading(P, S', z) 


if R = () or 5 = () 
if Ro = 0 


( (z) || spreading((i?o—1) || i?, S , z) otherwise 
spreading((3,l), (-7,-1), 0) = (0,0,0,-7, 0,-1) 


Subseries is a generalization of the tail function. It creates a series of the elements of 
its input from the nth up to but not including the mth. The first element in a series has 
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the 

inp 


index 0. If m is greater than or equal to the length of S, output stops as soon as the 
Ut runs out of elements. The example takes a chunk out of the middle of a series. 


one 

widf 


a 


0 if m = 0 or S = () 

subseries(5, n, m) = ^ subseries(^, n— 1, m—1) if n > 0 

(So) || subseries^, 0, m— 1) otherwise 
subseries((l, 1,2,2,3,3,4,4), 2, 5) = (2,2,3) 

-The function chunk is different from the ones above, because it can produce more than 
output. It has the effect of breaking a series S into (possibly overlapping) chunks of 
jth m > 0. Successive chunks are displaced n > 0 elements to the right, in the manner 
moving window. Chunk produces m output series. The ith chunk is composed of 
zth elements of the m outputs. Suppose that the length of S is /. The length of each 
out is [1 + (/—m)/nj. By itself, chunk may appear somewhat unusual, however, it 
uite useful in combination with other transducers. For instance, the example shows 
[ chunk could be used as part of the computation of a moving average. (Programming 
;uages differ in the mechanisms that could be used to channel the outputs of chunk 
e inputs of mapping.) 


chunk(m, n, S) = 
R k = 

chunk(l, n, S) = 


R 1 , ..., R m where 

chunk(l, n, subseries(5, k-l, oo)) 

| 0 if S' = () 

\ (So) || chunk(l, n, subseries(,S', n, oo)) otherwise 


chunk(2, ,1 ,(1,5,3,7)) = (1,5,3), (5,3,7) 
mapping(A xy. (x+y)/2, (1,5,3), (5,3,7)) = (3,4,5) 

fhe list of functions above can be viewed as a recommendation for the kind of func¬ 
tion^ that can profitably be supported in conjunction with a sequence data type. As 
disctissed in Section 7, some languages (e.g., APL) support most of these functions; oth- 
ers le.g., Pascal) support almost none of them. 


does 


The list of functions is also interesting for what it does not contain. To start with, it 
not contain functions for accessing arbitrary series elements or altering the value of 
series elements. This reflects the fact that, unlike vectors or lists, series are not intended 
to bte used as mutable data storage. 

In addition, the choice of functions is significantly influenced by the optimizability 
rest rictions in the last section. The list only includes functions that can be implemented 
as p reorder procedures using small fixed amounts of internal storage. (The only common 
functions ruled out by this criteria are ones like reversal, rotation, and sorting that 
rearrange the order of the elements of a sequence.) The list also favors functions that 
can be implemented as on-line procedures, because these are more useful in optimizable 
expressions. (The only functions in the list that require off-line implementation are 
concatenating, tail, mingling, choosing, spreading, subseries, and chunk.) 
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4. A Common Lisp Implementation 

Series can be added into essentially any programming language by adding an imple¬ 
mentation of the series data structure and defining a set of procedures supporting the 
series functions in Section 3. The optimization of series expressions can be supported by 
a preprocessor (see Section 6). It is in the nature of Lisp, that both of these things are 
^asy to do using a macro package. Such a macro package has been in regular use for a 
plumber of years and is generally available (see [46, 47]). 

Series. In the Lisp implementation, series are implemented lazily using closures. A 
Series has a procedural part and a data part. The procedural part is a generator [18, 29] 

capable of computing the elements one by one. The data part records the elements 
Computed so far. 

The elements of a series are accessed using a second generator that enumerates the 
Elements in the data part of the series and then uses the procedural part to compute 
pnore elements as needed. Each time the generator is called, it returns another element 
in the series. The generator takes a procedure argument that specifies what to do when 
the series runs out of elements. 

The two-level generation scheme above ensures that: elements are not computed 
Until needed, no element is computed twice, and each user of a series can access all 


(setq first5 ; Implementation of (1,2,3,4,5). 

(let ((x 0)) 

(list #’(lambda (at-end) 

(if (< x 5) (setq x (+ x 1)) (funcall at-end)))))) 

(defun generator (s) ; Returns a generator for the elements of a series, 

(let ((g (car s))) 

#’(lambda (at-end) 

(when (null (cdr s)) 

(setf (cdr s) 

(block nil 

(list (funcall g #’(lambda () (return T) )))))) 

(if (not (eq (cdr s) T)) 

(car (setq s (cdr s))) 

(funcall at-end))))) 

(defun choose-if (p s) ; Implementation of choosing(’P, S). 

(let ((gen (generator s))) 

(list #>(lambda (end-action) 

(loop (let ((x (funcall gen end-action))) 

(if (funcall p x) (return x)))))))) 

(defun collect-sum (s) ; Implementation of collection(0, A xy.x+y, S ). 

(let ((gen (generator s)) ' 

(sum 0)) 

(loop (let ((x (funcall gen #’(lambda () (return sum))))) 

(setq sum (+ sum x)))))) 

(collect-sum (choose-if #»oddp first5)) =>► 9 

Figure 4.1: Illustration of the Lisp implementation of unoptimized series. 
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elements. For those familiar with Lisp, Figure 4.1 illustrates the implementation of 
series data structures. The same basic implementation approach is used in the language 
Seque [19]. 

The closure implementation of series is effective and straightforward; However, it is 
very efficient. No effort has been expended on producing a more efficient imple¬ 
mentation, because the focus of series expressions is on the situations where they can 
be optimized, eliminating the physical representation of series altogether. In situations 
whc re optimization is impossible, it is usually better to represent a sequence as a vector 
or list than as a series. 

The protocol above for obtaining a generator for the elements of a series and thence 
elements themselves is not an exported part of the series implementation. Users must 


manipulate series using the series procedures below. This is important in the interest of 
opt: mizability in general and static analyzability in particular. 

Series procedures. The series functions described in Section 3 are all supported 
by Lisp procedures as shown in Figure 4.2. In addition, the # macro character syntax 
#Z( ? y ... z ) is provided for reading and printing literal series. The difference between 
ma k ^-series and #Z is that the arguments to #Z are implicitly quoted, while the arguments 
to njake-series are evaluated one at a time as needed. 

(catenate (make-series 1 (+2 2)) #Z(7 8)) #Z(1 4 7 8) 

(collect-first (choose-if #’oddp #Z(8 -7 6 -1))) => -7 
(subseries (mingle #Z(1 5 9) #Z(2 6 8) #’<) 2 4) => #Z(5 6) 
(multiple-value-bind (xs ys) (chunk 2 1 #Z(1 5 3 7)) 

(map-fn T #’(lambda (x y) (/ (+ x y) 2)) xs ys)) => #Z(3 4 5) 

'the higher-order procedures implementing scanning, collecting, mapping, truncating, 
and collection are extended so that they can accept multiple series arguments and produce 


Series Function 
S 0 

R || S 

scanning^, T, V) 
collection( jz, T, S) 
collecting^, T, S) 
mapping^, S 1 , ..., S n ) 
truncating^, S) 
mingling(i?, S , V) 
choosing^, S) 
spreading (R, S, z) 
subseries (S', n, m) 
chunk(m, n , S) 


Lisp Implementation 
(make-series x y ... z) 
(collect-first S) 

(subseries S 1) 

(catenate R S ) 

(scan-fn type Z T V) 

(collect-fn type Z T S 1 ... S n ) 
(collecting-fn type Z T S 1 ... S n ) 
(map-fn type T S 1 ... S n ) 

(until-if V S 1 ... S n ) 

(mingle R S V) 

(choose-if V S') 

(spread R S z) 

(subseries S n m) 

(chunk m n S) 


Figure 4.2: Lisp support for series functions. 
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multiple values. (Series of tuples could be used to get the same effect in any given 
situation. However, using multiple series values is usually more convenient and almost 
always more efficient than using tuples.) 

The examples below illustrate the Lisp procedure scan-fn, which supports scanning. 
In the second example, a two-valued stepping procedure is used and two series are re¬ 
turned (the unbounded series of natural numbers and a series of their partial sums). 
While scanning is in progress, two internal states are maintained. The stepping pro¬ 
cedure must accept as many values as it returns. Each of these values is treated as a 
separate state variable. 

(scan-fn ’list #’(lambda () ’(a b c d)) #’cddr #’null) 

=> #Z((a bed) (c d)) 

(scan-fn *(values integer integer) 

#*(lambda () (values 1 1)) 
j #’(lambda (i sum) 

(setq i (+ i 1)) (values i (+ sum i)))) 

=> #Z(1 234 ...) and #Z(1 3 6 10 ...) 


Three other features of scan-fn are worthy of note. First, a new first argument is 
Introduced, which specifies the type (or types) of the values returned by the stepping 
procedure. Given the lack of typing information in Lisp, this argument is necessary 
1:0 ensure that the number of arguments returned by the stepping procedure can be 
determined at compile time. Second, the initial value is replaced by a procedure that 
returns the initial values. This is convenient in situations where multiple initial values 
ire needed. Third, the predicate argument is made optional. Omitting it is the same as 
supplying a predicate that is not true of any value. The first and second extensions are 
upplied to collect-fn, collecting-fn, and map-fn as well as scan-fn. 

As a convenience to the user, a number of specific scanners are provided in addition 
|o scan-fn. These include: series which creates a series indefinitely repeating a given 
lvalue, scan which enumerates the elements in a list, vector, or string, scan-range which 
^numerates the integers in a range, and scan-plist which creates a series of the indicators 
jn a property list along with a second series containing the corresponding values. The 
lirst argument of scan specifies the type of object to be scanned. If omitted, the type 
defaults to list. 


(series "test") =£- #Z("test" "test" "test" ...) 
(scan ’(a b c)) =$► #Z(a b c) 

(scan ’vector ’#(a b c)) #Z(a b c) 

(scan ’string "Tuz") => #Z(#\T #\u #\z) 
(scan-range :from 1 :upto 3) =>■ #Z(1 2 3) 
(scan-plist ’(a 1 b 2)) => #Z(a b) and #Z(1 2) 


Similarly, a number of specific collectors are provided including: collect which com- 
Hmes the elements of a series into a list, vector, or string, collect-sum which adds up the 
dements of a series, collect-length which returns the number of elements in a series, 
And collect-last which returns the last element of a series (or an optional default value 

4 ser * es is empty)- The first argument of collect specifies the type of object to be 
produced. If omitted, the type defaults to list. 
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(collect #Z(a be)) =>• (a b c) 

(collect dimple-vector #Z(a b c)) =$► #(a b c) 

(collect ’string #Z(#\T #\u #\z)) =£► "Tuz" 

(collect-sum #Z(1 3 2)) =>■ 6 

(collect-length #Z("fee" "fi" "fo" "fum")) =>► 4 
(collect-last #Z("fee" "fi" "fo" "fum")) =*► "fum" 

(collect-last #Z() "none") =>> "none" 

finally, a number of additional transducers are provided including: previous (based 
on n ap-f n) which takes in a series and shifts it over one element by inserting the indicated 
valie at the front and discarding the last element, choose (based on choose-if) which 
sele :ts the elements of its second argument that correspond to non-null elements of its 
first argument, and positions (also based on choose-if) which returns the positions of 
the non-null elements in a series. If given only one argument, choose returns the non-null 
elen Lents of this series. 

(previous #Z("fee" "fi" "fo" "fum") " ") =$► #Z(" " "fee" "fi" "fo") 

(choose #Z(T nil T) #Z(1 2 3)) => #Z(1 3) 

(choose #Z(nil 3 4 nil)) #Z(3 4) 

(positions (map-fn #’oddp #Z(1 23568))) =>► #Z(0 2 3) 

Convenient support for mapping. In cognizance of the ubiquitous nature of 
mai ping, the Lisp series implementation provides three mechanisms that make it easy 
to e xpress particular kinds of mapping. The # macro character syntax #M^* converts a 
pro< edure T into a transducer that maps T. 

(#Msqrt #Z(4 16)) = (map-fn T #»sqrt #Z(4 16)) =£• #Z(2 4) 

The form mapping can be used to specify the mapping of a complex computation over 
one or more series without having to write a literal lambda expression. It has the same 
basic syntax as let. For example, 

(mapping ((x (scan ’(2 -2 3)))) 

(expt (abs x) 3)) =£► #Z(8 8 27) 

is tl(e same as 

(map-fn T #’(lambda (x) (expt (abs x) 3)) 

(scan ’(2 -2 3))) => #Z(8 8 27) 

'the form iterate is the same as mapping except that the value nil is always returned. 

(iterate ((x (scan ’(2 -2 3)))) 

(if (plusp x) (prinl x))) =>* nil <after printing “23”> 

to a first approximation, iterate and mapping differ in the same way as mape and 
map<iar. In particular, like mape, iterate is intended to be used in situations where the 
bod^ is being evaluated for side effect rather than for its result. However, due to the lazy 
evaluation nature of series, the difference between iterate and mapping is more than just 
a question of efficiency. If mapping is used in a situation where the output is not used, no 
commutation is performed, because series elements are not computed until they are used. 

Hested loops. The equivalent of a nested loop is expressed by simply using a series 
expijession in a procedure that is mapped over a series. This is typically done using 
mapping. In the example, a list of sums is computed based on a list of lists of numbers. 
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(let ((data ’((1 23) (45 6) (7 8)))) 

(collect 

(mapping ((number-list (scan data))) 

(collect-sum (scan number-list))))) =£► (6 15 15) 


User-defined series procedures. As shown by the definitions of collect-sum 
and mapping below, the standard Lisp forms defun and defmacro can be used to de¬ 
fine new series procedures. However, the Series macro package must be informed when 
a series procedure is being defined with defun. This is done by using the declaration 
pptimizable-series-function. No special declaration is required when using defmacro. 

(defun collect-sum (numbers) 

(declare (optimizable-series-function)) 

(collect-fn ’number #’(lambda () 0) #’ + numbers)) 

(defmacro mapping (var-value-pair-list ftbody body) 

(let* ((pairs (scan var-value-pair-list)) 

(arg-list (collect (#Mcar pairs))) 

(value-list (collect (#Mcadr pairs)))) 

‘(map-fn T #’(lambda ,arg-list ,fi body) ,® value-list))) 


Example. The following example shows what it is like to use series expressions in a 
ealistic programming context. The example consists of two parts: a pair of procedures 
hat convert between sets represented as lists and sets represented as bits packed into an 
nteger and a graph algorithm that uses the integer representation of sets. 

Sets over a small universe can be represented very efficiently as binary integers where 
jjach 1 bit in the integer represents an element in the set. Here, sets represented as binary 
(ntegers are referred to as bit sets. 

Common Lisp provides a number of bitwise operations on integers, which can be used 
I* 0 manipulate bit sets. In particular, logior computes the union of two bit sets while 
|.ogand computes their intersection. 

The procedures in Figure 4.3 convert between sets represented as lists and bit sets. 
To perform this conversion, a mapping has to be established between bit positions and 
potential set elements. This mapping is specified by a universe. A universe is a list of 
•(dements. If a bit set integer b is associated with a universe u , then the «th element in u 


(defun bset->list (bset universe) 

(collect (choose (#Mlogbitp (scan-range :from 0) (series bset)) 

(scan universe)))) 

(defun list->bset (items universe) 

(collect-fn ’integer #’(lambda () 0) #’logior 
(mapping ((item (scan items))) 

(ash 1 (bit-position item universe))))) 

(defun bit-position (item universe) 

(or (collect-first (positions (#Neq (series item) (scan universe)))) 
(1- (length (nconc universe (list item)))))) 

Figure 4.3: Converting between lists and bit sets. 
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(defun collect-logior (bsets) 

(declare (optimizable-series-function)) 

(collect-fn integer #’(lambda () 0) t’logior bsets)) 

(defun collect-logand (bsets) 

(declare (optimizable-series-function)) 

(collect-fn ’integer #’(lambda () -1) t’logand bsets)) 



Figure 4.4: Operations on series of bit sets. 

is ii| the set represented by b if and only if the zth bit in b is 1. For example, given the 
^erse (a b c d e), the integer #b01011 represents the set {a,b,d}. (By Common Lisp 
mention, the Oth bit in an integer is the rightmost bit.) 

liven a bit set and its associated universe, the procedure bset->list converts the bit 
|nto a set represented as a list of its elements. It does this by scanning the elements 
le universe along with their positions and constructing a list of the elements that 
jspond to Is in the integer representing the bit set. (When no :upto argument is 
su pjblied, scan-range counts up forever.) 

The procedure list->bset converts a set represented as a list of its elements into a 
bit set. Its second argument is the universe that is to be associated with the bit set 
cre« ted. For each element of the list, the procedure bit-position is called to determine 
whi:h bit position should be set to 1. The procedure ash is used to create an integer 
with the correct bit set to 1. The procedure collect-fn is used to combine the integers 
con esponding to the individual elements together into a bit set corresponding to the list. 

The procedure bit-position takes an item and a universe and returns the bit position 
con esponding to the item. The procedure operates in one of two ways depending on 
whether or not the item is in the universe. The first line of the procedure contains a 
seri ;s expression that determines the position of the item in the universe. If the item is 
not in the universe, the expression returns nil. (The procedure collect-first returns 
nil if it is passed an empty series.) 

f the item is not in the universe, the second line of the procedure adds the item onto 
the end of the universe and returns its position. The extension of the universe is done 
by f ide effect so that it will be permanently recorded in the universe. 

figure 4.4 shows the definition of two collectors that operate on series of bit sets. The 
first procedure computes the union of a series of bit sets, while the second computes the 
intersection. 

jive variable analysis. As an illustration of the way bit sets might be used, consider 
following. Suppose that in a compiler, program code is being represented as blocks 
jjraight-line code connected by possibly cyclic control flow. The top part of Figure 4.5 
fs the data structure that represents a block of code. Each block B has several pieces 
(formation associated with it. Two of these pieces of information are the blocks that 
can branch to B and the blocks B can branch to. A program is represented as a list of 
blocks that point to each other through these fields. 

Jn addition to control flow information, each structure contains information about 
the Way variables are accessed. In particular, it records the variables that are written by 
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(defstruct (block (:conc-name nil)) 
predecessors ;Blocks that can branch to this one. 
successors ;Blocks this one can branch to. 
written ;Variables written in the block. 

used ;Variables read before written in the block. 

liv « ;Variables that must be available at exit, 

temp) ;Temporary storage location. 

(defun determine-live (program-graph) 

(let ((universe (list nil))) 

(convert-to-bsets program-graph universe) 
(perform-relaxation program-graph) 

(convert-from-bsets program-graph universe)) 
program-graph) 

(defstruct (temp-bsets (:conc-name bset-)) 
used written live) 

(defun convert-to-bsets (program-graph universe) 

(iterate ((block (scan program-graph))) 

(setf (temp block) 

(make-temp-bsets 

:used (list->bset (used block) universe) 

:written (list->bset (written block) universe) 
:live 0)))) 

(defun perform-relaxation (program-graph) 

(let ((to-do program-graph)) 

(loop 

(when (null to-do) (return (values))) 

(let* ((block (pop to-do)) 

(estimate (live-estimate block))) 

(when (not (= estimate (bset-live (temp block)))) 
(setf (bset-live (temp block)) estimate) 

(iterate ((prev (scan (predecessors block)))) 
(pushnew prev to-do))))))) 

(defun live-estimate (block) 

(collect-logior 

(mapping ((next (scan (successors block)))) 

(logior (bset-used (temp next)) 

(logandc2 (bset-live (temp next)) 

(bset-written (temp next))))))) 

(defun convert-from-bsets (program-graph universe) 

(iterate ((block (scan program-graph))) 

(setf (live block) 

(bset->list (bset-live (temp block)) universe)) 
(setf (temp block) nil))) 


Figure 4.5: Live variable analysis. 
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the block and the variables that are used by the block (i.e., either read without being 
written or read before they are written). An additional field (computed by the procedure 
det ermine-live discussed below) records the variables that are live at the end of the 
block. (A variable is live if it has to be saved, because it can potentially be used by a 
following block.) Finally, there is a temporary data field, which is used by procedures 
(sui'h as determine-live) that perform computations involved with the blocks. 

The remainder of Figure 4.5 shows the procedure determine-live, which given a 
program represented as a list of blocks, determines the variables that are live in each 
bio ;k. To perform this computation efficiently, the procedure uses bit sets. The procedure 
operates in three steps. The first step (convert-to-bsets) looks at each block and sets 
up iin auxiliary data structure containing bit set representations for the written variables, 
the used variables, and an initial guess that there are no live variables. This auxiliary 
structure is defined by the third form in Figure 4.5 and is stored in the temp field of the 
block. The integer 0 represents an empty bit set. 

The second step (perform-relaxation) determines which variables are live. This is 
done by relaxation. The initial guess that there are no live variables in any block is 
successively improved until the correct answer is obtained. 

The third step (convert-from-bsets) operates in the reverse of the first step. Each 
block is inspected and the bit set representation of the live variables is converted into a 
list, which is stored in the live field of the block. 

On each cycle of the loop in perform-relaxation, a block is examined to determine 
whether its live set has to be changed. To do this (see the procedure live-estimate), 
the successors of the block are inspected. Each successor needs to have available to it 
the variables it uses, plus the variables that are supposed to be live after it, minus the 
vari jbles it writes. (The procedure logandc2 takes the difference of two bit sets.) A new 
esti] nate of the total set of variables needed by the successors as a group is computed by 
using collect-logior. 

] f this new estimate is different from the current estimate of what variables are live, 
thei the estimate is changed. In addition, if the estimate is changed, perform-relaxation 
has to make sure that all the predecessors of the current block will be examined to see 
whe ;her the new estimate for the current block requires their live estimates to be changed. 
This is done by adding each predecessor onto the list to-do unless it is already there. As 
soor as the estimates of liveness stop changing, the computation stops. 

Nummary. Figure 4.5 is a particularly good example of the way series expressions 
are ntended to be used in three ways. First, all the series expressions are optimizable. 
Second, series expressions are used in a number of places to express computations that 
woul d otherwise be expressed less clearly as loops or less efficiently using operations on 
lists or vectors. Third, the main relaxation algorithm in perform-relaxation is expressed 
as a loop. This is done, because the data flow in this algorithm prevents it from being 
decc|mposed into two or more fragments. This highlights the fact that optimizable series 
expr essions are not intended to render iterative programs entirely obsolete, but rather to 
provide a greatly improved method for expressing the vast majority of loops. 
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Series can be added to Pascal in much the same way as they are added to Lisp. A 
prototype system has been constructed that demonstrates this [28, 45]. However, the 
prototype is written in Lisp rather than Pascal and only supports optimizable series 
expressions. A fatal error is issued whenever optimization is blocked. Although less 
complete than the approach of the Lisp implementation, this still allows loops to be 
replaced by optimizable series expressions. 

Series. The Pascal series preprocessor supports the declaration of series in analogy 
with array declarations as shown below. (This is the only syntactic extension required to 
support series. Further, the output of the preprocessor is standard Pascal without any 
references to series.) In line with the general philosophy of Pascal, it is required that all 
the elements of a series have the same type. However, the length of a series is not part 
of its type. This is important to facilitate the definition of series procedures operating 
on series of arbitrary length. 

type Integers * series of Integer; 
var InputData: series of Real; 

j 

Series procedures. The series functions described in Section 3 are all supported by 
Pascal procedures as shown in Figure 5.1. In general, these have the same names as the 
corresponding Lisp procedures with any hyphens removed (e.g., scan-fn becomes ScanFn). 
Since Pascal does not support the concept of a function procedure that returns multiple 
values, the outputs of chunk are turned into arguments. (The examples in [28, 45] show 
an obsolete set of names linked to an earlier Lisp implementation of series.) The Pascal 
implementation does not provide a syntax for series literals. (The mathematical syntax 
is used in the examples below.) 


Series Function 

Vt • • • ? 

So 

y 

R\\S 

scanning^, T, V) 
collection^, T, S) 
collecting^, T, S) 
mapping^, S 1 , ..., S n ) 
truncating^, S) 
mingling^, S, V) 
choosing^, S) 
spreading(i?, S, z) 
subseries(5, n, m) 
chunk(m, n, S) 


_ Pascal Impleme ntation 

MakeSeries(r, y, ..., z) 
CollectFirst(S) 

Subseries (S , 1) 

Catenate (R, S ) 

ScanFn( 2 , T , V) 

CollectFn(z, T, S ) 

CollectingFn(z, T, S) 
MapFnCF, 5 1 , ..., S n ) 
Truncatelf (P, S ) 

Mingle (R, S y V) 

ChooselfCP, S') 

Spread (R, S, z ) 

Subseries(5, n, m) 

Chunk (m, n t S , R 1 , ..., R m ) 


Figure 5.1: Pascal support for series functions. 
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Catenate(MakeSeries(l, 2+2), (7,8)) => (1,4,7,8) 

CollectFirst(Chooself(odd, (8,-7,6,-i))) =>► -7 
Subseries(Mingle((1,5,9), (2,6,8), <)) 2 4) => (5 6) 

Chunk(2, 1, (l,5,3,7), Xs, Ys) => Xs := (l,5,3) and Ys := (5,3,7) 

MapFn(Average, Xs, Ys) => (3,4,5) 
function Average (x,y: Integer): Integer; 
begin 

Average (x+y)/2 
end; 

The Pascal implementation does not extend the higher-order procedures over their 
specifications in Section 3 for two reasons. Given the strong typing in Pascal, the pre¬ 
processor can obtain type information without needing type arguments. Since, Pascal 
does not support the concept of multiple return values, some other method needs to be 
employed to avoid the need for tuples. 

The procedures in Figure 5.1 do not follow the usual Pascal restrictions on the pa¬ 
rameters of procedures. Some of the procedures allow the number of arguments they 
receive to vary and they all allow considerable flexibility in the types of their arguments. 
This is important because the series procedures are inherently generic in character. For 
instance, MapFn is naturally applicable to any number and any type of series as long as 
the element types are compatible with the procedure being mapped. 

Due to their generic nature, the procedures in Figure 5.1 could not be implemented 
as user-defined procedures in Pascal. However, as an extension to the language, they 
do not violate the spirit of Pascal. In particular, the predeclared Pascal procedures are 
generic in exactly the same way. Several (e.g., Read and Write) allow variable numbers 
of arguments and most of them are applicable to more than one type of object. Using 
a more flexible language such as Ada [50], it would be possible to implement (at least 
most of) the higher-order series functions as user-defined procedures. 

AH of the specific scanners, collectors, and transducers from the Lisp implementation 
that are applicable to Pascal are supported by the Pascal implementation as well. Given 
the strong typing in Pascal, Scan and Collect do not need type arguments. Since Pascal 
has sets, but not lists, these functions apply to sets and not lists. In keeping with 
the general style of Pascal, Collect takes the destination vector/string/set as its first 
argument rather than returning an aggregate value. 

Series(’test’) =>► (’test 1 ,’test’,’test>, ...) 

Scan( , Tuz > ) =£► (»T»,»u*,*z*) 

Scan([Mon,Wed,Fri]) =>• (Mon,Wed,Fri) 

ScanRange(l, 3) => (l,2,3) 

Collect(X, (*T*,*u * ,*z*)) { Places ’luz* in X. } 

CollectSum((l,3,2)) =£► 6 
CollectLength(( , fee > ,»fi»,»fo»,’fum’)) =>■ 4 
CollectLast((’fee’,*fi*,’fo*,’fum’)) =>► >fum> 

CollectLast((), ’none’) =£► ’none’ 

Previous((’fee* »fi» ’fo> ’fum’), » ») => (> » >f ee > >fi> > fo >\ 

Choose((true,false,true), (l,2,3)) =► (13) ' ’ ' } 

Positions(MapFn(Odd, (l,2,3,5,6,8))) => #Z(0 2 3) 
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Implicit mapping. To avoid making syntactic extensions, the Pascal implemen¬ 
tation does not support constructs analogous to the Lisp forms mapping and iterate, 
lowever, it supports a related concept that is in many ways even more useful. Whenever 
i non-series procedure is applied to a series, it is automatically mapped over the elements 
>f the series. For example, in the expression below, Sqr is automatically mapped over 
he series of numbers created by scanning the set. 

CollectSum(Sqr(Scan([2,4]))) 

= CollectSum(MapFn(Sqr, Scan([2,4]))) => 20 


The key virtue of implicit mapping is that it reduces the number of helping procedures 
that have to be defined. For instance, in the example of a moving average above, you 
jean write the following instead of defining a procedure Average and explicitly mapping 

Chunk(2, 1, (l,5,3,7>, Xs, Ys); (Xs+Ys)/2 => (3,4,5) 

The concept of implicit mapping is completely separate from the other concepts as¬ 
sociated with series expressions. As such, it could easily be dispensed with. However, 

[ is shown by experience with APL and the other languages that support it, implicit map- 
)ing is extremely useful. (The lack of reliable compile-time type information makes it 
mpractical to support implicit mapping in Lisp.) 

User-defined series procedures. As shown in the examples below, series proce¬ 
dures in Pascal are simply procedures that either have series inputs or return series values. 
As with series in general, all such definitions are handled directly by the preprocessor. 
There is no need for any special kind of declaration. Pascal does not support the concept 
'pf macros. 

Example. The following example illustrates how series expressions can best be used 
in Pascal. As in the last section, all of the expressions are optimizable. The example 
evolves around a job queue data abstraction that might be used in an operating system. 
The basic type definition is shown below. A JobQ is a pointer to a chain of entries 
hat point to records describing jobs. These records have a number of fields including a 
numerical priority. 

type JobQ * fJobQentry; 

type JobQentry * record; Job: Joblnfo; Rest: JobQ end; 
type Joblnfo * fJobRecord; 

type JobRecord * record Priority: Real; ... end; 


There are a number of procedures defined that operate on job queues. These proce¬ 
dures include putting a new job onto a queue (shown below) and removing a job from a 
queue (discussed near the end of this section). To add a job onto a queue, one merely 
needs to allocate a new queue entry and attach it to the front of the queue. 


procedure AddToJobq (J: Joblnfo; var Q: JobQ); 

var E: fJobQentry; 
begin 
new(E); 

Ej.Job := Joblnfo; 

Ej.Rest := Q; 

Q := E 
end 
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In addition to ordinary procedures that operate on job queues, it is useful to define 
umber of series procedures that operate on job queues. In particular, as with any 
aggregate data structure, it is useful to have procedures ScanJobQ and CollectJobQ that 
cor vert job queues to series of jobs and vice versa. It also turns out to be useful to have 
a p 'ocedure ScanJobQtails that enumerates all of the tails of a queue (i.e., (Q, Q|. Rest, 
Q|.Restj.Rest , ...)). As shown below, ScanJobQtails can be implemented using the 
hig|i6r-order series procedure ScanFn and two special-purpose procedures operating on 


job 


queues. 


function ScanJobQtails (Q: JobQ): series of JobQ; 
function JobQrest (Q: JobQ): JobQ; 

begin JobQrest := Qf.Rest end; 
function JobQnull (Q: JobQ): Boolean; 
begin JobQnull :* Q=nil end; 
begin 

ScanJobQtails := ScanFn(Q, JobQrest, JobQnull) 
end 


beld 
ing 
Scab 


p.mong other things, ScanJobQtails can be used to implement ScanJobQ as shown 
w. The expression Qs| .Job causes the operations of following a pointer and select- 
the job field of a JobQentry to be implicitly mapped over the pointers returned by 
JobQtails. 


function ScanJobQ (Q: JobQ): 

var Qs: series of Jobq; 
begin 

Qs :* ScanJobQtails(Q); 
ScanJobQ :* Qsf.Job 
end 


series of Joblnfo; 


impf 
me: 
the 
ret 
job 
rem|0 
itse 


The procedure RemoveFromJobQ removes a job from the end of a queue. It can be 
emented using ScanJobQtails as shown below. To start with, RemoveFromJobQ enu- 
tijates the tails of the queue and uses CollectLast and Previous to obtain pointers to 
last and next to last entries in the queue. The job field of the last queue entry is 
ijrned as the result of RemoveFromJobQ. (It is assumed that there must be at least one 
in the queue.) The rest pointer in the next to last entry is set to nil, in order to 
ve the last entry from the queue. (If there is no next to last entry, the queue variable 
f is set to nil.) The storage associated with the last entry is then freed. 


function RemoveFromJobQ (var Q: JobQ): Joblnfo; 
var Qs: series of JobQ; 

NextToLast, Last: JobQ; 

begin 

Qs := ScanJobQtails(Q); 

Last := CollectLast(Qs, nil); 

NextToLast CollectLast(Previous(Qs, nil), nil); 
RemoveFromJobQ := Lastf.Job; 
if NextToLast=nil 
then Q := nil 

else NextToLast.Rest := nil; 
dispose(Last) 
end 
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The first three lines of the body of RemoveFromJobQ are a series expression, while the 
Remainder are non-series expressions. From an efficiency standpoint, it should be noted 
that since there is only one instance of ScanJobQtails, the series expression is converted 
into a loop that only traverses the queue once. 

As a final example of the use of optimizable series expressions, consider the procedure 
SuperJob below. This procedure inspects a job queue and returns the last (i.e., longest 
queued) job in the queue whose priority is more than two standard deviations larger than 
the average priority of the jobs in the queue. If there is no such job, nil is returned. The 
first five statements in the procedure compute the mean and deviation of the priorities. 
The next two statements select the jobs that have sufficiently large priorities. The final 
ine selects the last of these jobs, if any. 


function SuperJob (Q: JobQ): Joblnfo; 
var Jobs, SuperJobs: series of Joblnfo; 

N: Integer; 

Mean, SecondMoment, Deviation, Limit: Real; 

begin 

Jobs :■ ScanJobQ(Q); 

N := CollectLength(Jobs); 

Mean :« CollectSum(Jobs.Priority)/N; 

SecondMoment :* CollectSum(Sqr(Jobs.Priority))/N; 
Deviation :* Sqrt(SecondMoment-Sqr(Mean)); 

Limit := Mean+2*Deviation; 

SuperJobs := Choose(Jobs.Priority>Limit, ScanJobQ(Q)); 
SuperJob :■ CollectLast(SuperJobs, nil) 
end 


be 


The programs above are a good example of the way series expressions are intended to 
used. To start with, all of the programs are straightforward in nature. This reflects 
the fact that the primary goal of series expressions is to convert the vast majority of 
programs that are in fact straightforward programs into dirt simple programs. When 
il P r °g ram is straightforward, it is usually easy to write it in a loop-free form without 
having to use anything other than very simple series expressions. 
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6. The Optimization Algorithms 

A preprocessor or compiler extension that transforms optimizable series expressions 
into loops can be implemented in three stages: parsing which locates optimizable expres¬ 
sions and converts them into equivalent data flow graphs, pipelining which converts the 
exp ressions into loops, and unparsing which converts the resulting loops into appropriate 
program code and inserts this code in place of the original expressions. 

Below, the Pascal implementation of series is used as a concrete illustration. The 
Coi nmon Lisp implementation works in the same way, except that the characteristics of 
Lis ) simplify the parsing and unparsing stages. 

Parsing. When the preprocessor is applied to a program, it begins by parsing the 
pro Tram. Series expressions are located by inspecting the types of the procedures called 
by the program. While this is being done, the static analyzability and straight-line 
computation restrictions are checked and any violations reported. 

In a language like Pascal where complete compile-time type information is available, 
imp licit mapping can be supported by noting places where non-series functions are ap¬ 
plied to series. Each such application is replaced by an appropriate use of MapFn. 

The final action of the parsing stage is to create a data flow graph corresponding to 
eac i optimizable series expression located. Since each of these expressions is a straight- 
line computation, this is easy to do. Each procedure call becomes a node in the graph 
and the data flow between the nodes is derived from the way procedure calls are nested 
and the way variables are used. 

Pipelining. The operation of the pipelining stage is illustrated in Figure 6.1. The 
serips expression in the procedure SumSqrs (which computes the sum of the squares 
of the odd elements of a vector) is transformed into the loop shown in the procedure 
Sum >qrsPipelined. The readability of the loop code is reduced by the fact that it con¬ 
tains a number of internally generated variables. However, the code is quite efficient. The 
only significant problem is that the pipeliner sometimes uses more variables than strictly 
necessary (e.g., Result5). However, this need not lead to inefficiency during execution as 
lonj; as a compiler capable of simple optimizations is available. 

The pipelining process operates in several steps. In the first step, the divide and 
conquer strategy discussed in Section 2 is used to partition the data flow graph for a 
sen. is expression into subexpressions where all the data flow connects on-line ports. While 

doii g this, the pipeliner checks that the expression obeys the sequence intermediate value 
and on-line cycle restrictions. 

1 )nce partitioning is complete, the procedures in each subexpression are combined into 
a si] igle procedure. The resulting procedures are then combined based on the data flow 
between the subexpressions. To support the combination process, each series procedure 
is re presented as a loop fragment with one or more of the following parts: 
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function SumSqrs (V: array [1..N] of Integer): Integer; 
begin 

SumSqrs := CollectSum(Sqr(ChooseIf(Odd, Scan(V)))) 
end 

U- 

function SumSqrsPipelined (V: array [1..N] of Integer): Integer: 
label 0,1; 

Var Element12, Indexl5, Result5, Sum2: Integer; 
begin 

[1] Indexl5 := 0; 

[4] Sum2 := 0; 

[1] 1: Indexl5 := 1+Indexl5; 

[1] if Indexl5>N then goto 0; 

[1] Element12 := V[Indexl5]; 

[2] if Odd(Element12) then goto 1; 

[3] Result5 :* Sqr(Element12); 

[4] Sum2 :* Sum2+Result5; 
goto 1; 

0: SumSqrsPipelined :* Sum2 
end 


[1] — Scan of a vector - 

inputs- Vector: array IK..L ] of ElementType; 
outputs- Element: Series of ElementType; 

vars- Index: Integer; 
prolog- Index: 1 -K; 

body- Index := 1+Index; 

if Index>L then goto 0; 

Element :* Vector[Index]; 

[2] — Chooself - 

inputs- function P(X: ElementType ): Boolean; 

Item: Series of ElementType; 
outputs- Item: Series of ElementType ; 
labels- 2; 

body- 2: Nextln(Item); if P(Item) then goto 2; 

[3] — Implicit mapping of Sqr - 

inputs- Item: Series of ElementType ; 
outputs- Result: Series of ElementType; 
body- Result := Sqr(Item); 

[4] — CollectSum - 

inputs- Number: Series of ElementType; 
outputs- Sum: ElementType; 
prolog- Sum := 0; 

body- Sum := Sum+Number; 

Figure 6.1: Transforming optimizable series expressions into loops. 
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Input variables. 

Output variables. 

Auxiliary variables used by the computation. 

Labels used by the computation. 

Statements that are executed before the computation starts. 
Statements that are repetitively executed. 

Statements that are executed after the loop terminates. 


The bottom part of Figure 6.1 shows the fragments that represent the procedures 
ed by the series expression in SumSqrs. These fragments are combined to create the 
loo ) in SumSqrsPipelined. The numbers in the left hand margin indicate which fragment 
i line of the loop comes from. Two different combination algorithms are used: one 
corresponding to data flow between on-line ports and one corresponding to data flow 
tou:hing off-line ports. 

When two procedures are connected by data flow connecting on-line ports (e.g, the 
dat i flow from the output of Sqrs to the input of CollectSum), the procedures are corn- 
bin id by simply concatenating the various parts of the corresponding fragments together. 
In i addition, the variables and labels in the fragments are renamed so that there will be 
possibility of conflicts. The data flow between the procedures is implemented by re- 
nan ling the input variable of the destination so that it is the same as the output variable 
of t be source. (The process above is much the same as an application of the standard 
compiler optimization technique of loop fusion [3].) 

When two procedures are connected by series data flow terminating on an off-line 
it (e.g., the data flow from the output of Scan to the series input of Chooself in the 
figure), the fragment representing the destination procedure contains an instance of the 
form Nextln, which specifies when elements of the input should be computed. The two 
frag ments are combined exactly as in the on-line combination algorithm except that the 
body of the source fragment is substituted in place of the call on Nextln, rather than 
being concatenated with the body of the destination fragment. (This process essentially 
con piles in support for a simple case of lazy evaluation [16].) 

Jnparsing. The result of pipelining is a single loop fragment that corresponds to 
series expression as a whole. In the unparsing stage, this fragment is converted into 
op as indicated below. The combination process eliminates the inputs. The other 
s of the fragment appear directly in the loop except for the outputs. 

label 0,1, labels; 

var vars; 
begin 
prolog; 

1: body; 

goto 1; 

0: epilog; 


the 
a lol 
par 


into 

beeb 


j^he outputs are connected up to the surrounding code when the loop is substituted 
the program in place of the original series expression. Once each series expression has 
replaced by a loop, the resulting code can be passed to a standard Pascal compiler. 
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Side-effects. The correctness preserving nature of the transformations above has 
[been shown under the assumption that there are no side-effects involved. It is believed 
that if unoptimized series are implemented as shown in the beginning of Section 4, the 
transformations are also correctness preserving in the presence of side-effects. The reason 
for this is that the transformed code exactly mimics the lazy evaluation of the untrans¬ 
formed expression. For instance, the off-line port combination algorithm involves code 
motion; however, this motion simply moves the generation of the series elements to the 
[place where lazy evaluation requires the elements of the series to be first computed. 

The above can be made more formal from the point of view of path analysis [10]. 
Path analysis seeks to determine at compile time where in a program each lazy value will 
be first used and where it will be reused. This information can be used to optimize lazy 
evaluation in two ways. If there is an identifiable place of first use of a given value then 
ordinary evaluation can be used instead of lazy evaluation for that value. If there is an 
identifiable last use for a value, the value does not have to be stored beyond that time. 

The restrictions in Section 2 guarantee that for each series, there is an identifiable 
place where each element of the series is first used and that, for each element, the last 
use precedes the computation of the next element. The transformations above merely 
position the computation of the elements at their place of first use and omit their long 
term storage. 

The above notwithstanding, one should realize that side-effects are still problematical, 

[ because lazy evaluation makes it difficult for programmers to figure out what the net 
esults of side-effects will be. Some situations can be readily understood. For example, 
ne can depend on the fact that mapping will apply the mapped function T first to the 
rst element of the input, then to the second, and so on in strict temporal order. Thus, 
T interacts with itself or the environment outside of the containing series expression X 
ia side-effects (e.g., by doing input or output), but does not interact with anything else 

l X, the result is easy enough to understand. More complex uses of side-effects should 
e avoided. 

Systems Based on Similar Algorithms 

The algorithms above have evolved into their current form over the past twelve years. 
The first generally available implementation was a Lisp macro package called LetS [42, 
43]. The current Lisp implementation [46] is available in Portable Common Lisp. 

The same basic approach to representing and combining sequence procedures was in¬ 
dependently developed by Wile [48]. However, he does not explicitly address the question 
of restrictions and his approach does not guarantee that every intermediate sequence can 
be eliminated. Much the same can be said about APL compilers [11]. 

A quite similar approach is also used internally by the Loop macro [12]. However, 
as discussed in the next section, the Loop macro is externally very different from se¬ 
ries expressions. In particular, it uses an idiosyncratic English-like syntax rather than 
ijepresenting computations as compositions of procedures operating on series. 
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7. Comparisons 

There are two primary vantage points from which to compare series expressions with 
related concepts. The most obvious comparison is with other support for sequence ex¬ 
pressions. From this perspective, the key feature of series expressions is that they support 
mo: it of the operations supported by the vector operations of APL [31], Common Lisp 
seq lence operations [36], and the stream operations of Seque [19] (along with a few 
add itional ones) while being more efficient. 

Another way to view series expressions is that they are a logical continuation of the 
trei .d in programming language design toward supporting the reuse of loop fragments. 
Fron this point of view, series expressions extend the approach taken by iterators in 
CLl [27] and the Lisp Loop macro [12]. The key feature of series expressions in this 
con ;ext is that they support the reuse of a wider variety of fragments and are easier to 
und erstand and modify, without being any less efficient. 

To lend depth to the comments above, the remainder of this section presents detailed 
con parisons between the Common Lisp implementation of series expressions and five 
othor systems. Each of these comparisons features the example below. This example 
sho vs the definition of a procedure that computes the sum of the positive elements of 
a vector. It also illustrates how a new series procedure can be defined. (The example 

assumes the existence of a procedure Positive that tests whether an integer is greater 
tha i zero.) 

function SumPositive (V: array [1..N] of Integer): Integer; 
begin 

SumPositive := CollectSum(ChooseIf(Positive, Scan(V))) 
end 

function CollectSum (S: series of Integer): Integer; 

I begin 

CollectSum := CollectFn(0, +, S) 
end 


Other Support for Sequence Expressions 

There are many programming languages that provide support for sequence expres¬ 
sions, e.g., [5, 6, 19, 25, 32, 34, 35, 36]. So many, that it would not be practical to make 
detc iled comparisons between each one of these languages and series expressions. Three 
representative languages are discussed below. 

APL. One of the oldest and must used languages that takes a functional approach is 
APL [23, 31]. A style of writing APL has evolved where vector expressions are used instead 
of lc ops. The correspondence between the series functions discussed in Section 3 and the 
APL vector operators is summarized in Figure 7.1. The APL concept of the extension of 
seal; ir operations to vectors corresponds to implicit mapping. 

As illustrated below, both the vector summation algorithm and user-defined sequence 
procedures can be very compactly represented in APL. Since each sequence is directly 
represented as a vector, there is no need for an operation analogous to Scan. 



Other Support for Sequence Expressions 


37 


V SUM<—SUMPOSITIVEAPL V 

[1] SUM+-C0LLECTSUM((V>0)/V) 

V 

v SUM<— COLLECTSUM NUMBERS 
[1] SUM <—+/NUMBERS 

! v 

The key differences between APL and series expressions are that APL vectors cannot 
represent unbounded sequences, the set of APL operations is somewhat different, and 
users are not given any feedback about what is efficient and what is not. 

Although all the series operations could have been supported in APL, there is no direct 
built-in support for scanning, mingling, or chunk. In addition, APL does not support 
higher-order operations as well as it might initially appear. For instance, the reduction 
operator appears to be a higher-order operation. However, at least in standard APL, the 
operation to be reduced must be one of the predefined scalar operations—user-defined 
operations cannot be used. As a result, the reduction operator is actually just part of a 
naming scheme for a small set of specific collectors. (This has the collateral benefit of 
allowing the initial identity value to be implicit.) 

APL supports four operations (reversal, membership, grade up, and grade down) that 
are not supported by series expressions because they cannot be implemented in a preorder 
'ashion using bounded storage. APL also allows the modification of the elements of a 
sequence. When using series expressions, one has to rely on other constructs in the host 
anguage when performing any of these operations. For instance, to sort a series in the 
Jsp implementation of series, one must first collect the series into a list and then sort 
-he list. Explicitly creating a list makes the expensive nature of sorting more obvious, 


Series Function 

APL Operation 

name 
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S[l] 
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Figure 7.1: The correspondence between series functions and APL operations. 
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ever, it does not make sorting more expensive, because sorting requires that some 
sical representation of the sequence be created. 

A few APL compilers [11, 21] are capable of producing efficient code in most of the 
situations where series expressions can be optimized; however, most are not. As a result, 
opt mizable series expression are typically much more efficient. Further, even when the 
con ipiler supports optimization, programmers are not given any feedback about whether 
opt mization will occur. Rather, programmers are (at least implicitly) encouraged not to 
think about such issues. 

An area where APL is fundamentally more powerful than series expressions is that 
standard intermediate structure in APL is the array. APL has a number of powerful 
army operators (not shown in Figure 7.1) and a few APL compilers can optimize some 
army expressions. In contrast, while it is possible to have series of series, there are no 
' *ial series operations for operating on them, and they are never optimized. 

Finally, a superficial but striking difference between series expressions and APL is that 
?s expressions use standard subroutine calling notation while APL uses a special set 
of concise, but cryptic, operators. 

Common Lisp Sequence Operations. While many (if not most) Lisp program¬ 
mer s use loops extensively, a style of writing Lisp has evolved where expressions com- 
ng intermediate lists and vectors are used instead of loops. Unfortunately, until 


rece ntly, Lisp supported an impoverished set of predefined sequence operations—it sup- 


ed mapcar, but not much else. When Common Lisp was designed [36], this defect 
rectified by introducing a relatively comprehensive suite of sequence operations. 

In Common Lisp, the term ‘sequence’ is used to refer to either a list or a vector. How- 
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Figure 7.2: 


The correspondence between series functions and sequence operations. 
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fever, since both of these structures are limited to representing bounded sequences, Lisp 
Sequences are not a complete implementation of mathematical sequences. The correspon¬ 
dence between the basic series functions and the Lisp sequence operations is summarized 
in Figure 7.2. Lisp does not support implicit mapping. 

The example below shows how the Common Lisp sequence operations can be used to 
Express the vector summation algorithm and a user-defined sequence procedure. Since a 
vector is a Lisp sequence, there is no need for a procedure analogous to scan. 

(defun sum-positive-sequence (v) 

(collect-sum (remove-if-not t’plusp v))) 

(defun collect-sum (numbers) 

(reduce #’+ numbers)) 

Except for the fact that Lisp sequences cannot represent unbounded sequences, there 
is no reason why all the series functions could not be supported by sequence operations. 
However, there is no direct built-in support for scanning, collecting, spreading, or chunk, 
m addition, the identity value to use for reduce (collection) is specified in an odd way. 
The procedure argument must be implemented in such a way that when called with zero 
arguments it returns the identity value. 

Current Lisp compilers do not optimize sequence expressions. As a result, optimizable 
teries expressions are much more efficient. In light of the lack of optimization, it is not 
surprising that Lisp provides no feedback about optimizability. As in APL, there is no 
pi as toward preorder functions and modification of sequence elements is allowed. It is 
also common to have sequences of sequences, however, Lisp does not provide any special 
Operations for manipulating them. 

An interesting aspect of the Lisp sequence operations is that they typically support 
k number of keyword arguments that modify their behaviors. For example, consider 
the sequence operation count-if , which takes a predicate and a sequence, and returns a 
tount of the number of elements in the sequence that satisfy the predicate. 

(count-if #’plusp ’(1 -234 -5)) =>> 3 

The Lisp operation count-if takes two keyword arguments : start and rend, which 
ban be used to specify a subsequence of the input in which counting is to occur. In 
addition, a keyword argument rkey can be used to specify an access procedure that will 
)e used to fetch the part of each sequence element that should be tested by the predicate, 
finally, an operation count-if -not exists, which is the same as count-if except that it 
mtomatically negates the values returned by the predicate. 

As illustrated by the example below, none of these options is strictly necessary. The 
(start and rand keywords can be dispensed with by using subseq. The rkay keyword 
imd count-if-not can be dispensed with by specifying complex predicates. 

(count-if-not ♦’plusp ’((1) (-2) (3) (4) (-5)) 

:start 0 rend 3 rkey #’first) 

= (count-if #’(lambda (element) (not (plusp (car element)))) 

(subseq ’((1) (-2) (3) (4) (-5)) 0 3)) => 1 
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Kevertheless, the various options described above are important for two reasons. First, 
promote efficiency. (Using subseq instead of the : start and rend keywords is ineffi- 
t, because it creates an intermediate sequence.) Second, they increase the probability 
predefined operations can be used as procedure arguments instead of lambda expres- 
s. This makes uses of count-if more concise and easier to read. 

Jsing series expressions, neither of these issues comes up. In the Lisp series expression 
w, the use of subseries does not lead to inefficiency, since pipelining eliminates the 
ical creation of its output series. Convenient support for mapping makes it possible 
c void the need for an explicit lambda expression. The desired test and key is simply 
pped over the series in question (again without inefficiency). Finally, count-if itself 
be dispensed with by using a combination of choose and collect-length. The 
p^oach taken by series expressions allows the individual procedures to be simpler and 
’ es things more functional in appearance. 

(let ((elements (subseries (scan ’((1) (-2) (3) (4) (-5))) 0 3))) 
(collect-length (choose (#Mnot (#Mplusp (#Mcar elements)))))) = 
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|>eque. Under the name of streams, sequences are the central data type of the 
;uage Seque [19]. Using the same basic lazy evaluation technique discussed in the 
nning of Section 4, Seque supports both bounded and unbounded sequences. The 
l espondence between the series functions discussed in Section 3 and the stream opera- 
s provided by Seque is summarized in Figure 7.3. As in APL, many of these operations 
provided by means of special syntax. In addition, implicit mapping is supported for 
y non-stream operations when they are applied to streams. 
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Figure 7.3: The correspondence between series functions and Seque operations. 
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! As illustrated below, both the vector summation algorithm and user-defined sequence 
procedures can be easily represented in Seque. Since streams are a distinct data type 
from vectors, an operation ! equivalent to Scan is required. 

procedure SumPositive (V) 

return CollectSum( [:!V: lambda(e) if e>0 then e] ) 

; end 

| procedure CollectSum (S) 

L :* Length(S) 

return if L=0 then 0 else Red(S, "+")!L 
end 

Since unbounded sequences are supported, it would be easy to completely support all 

t he series functions in Seque. However, there is no direct support for mingling, spreading, 
T chunk. In addition, collection is only indirectly supported by collecting, this leads 
o awkwardness when collection is applied to an empty sequence, because there is no 
pecification of the correct default value to return. There is also no direct support for 
he higher-order function scanning. However, there is an impressive array of facilities for 
iefining scanning functions, both in Seque and in the language Icon [18], which Seque is 
)ased on. It is interesting to note that like the series operations, all of Seque’s stream 
• >perations are preorder. 

Seque does not attempt to optimize the evaluation of stream expressions by eliminat- 
ng the computation of unnecessary intermediate streams. As a result, series expressions 
ire never less efficient and often much more efficient. Seque programmer’s are encouraged 
o think in terms of streams of streams and to make use of assigning to the elements of 
: itreams without any regard for the consequences on efficiency. 

Summary. In comparison with the languages above, series expressions have three 
principal advantages. They support a wider range of operations than any one of the 
anguages. Except in comparison with the best of APL compilers, they are much more 
1 efficient. They give clear feedback about what is efficient and what is not. As part of this, 
hey make the use of non-preorder procedures more awkward, by forcing the programmer 
o use the facilities of the host language. 

Looping Notations 

The fundamental virtues of series expressions in comparison with looping constructs 
ire illustrated by the discussion in the beginning of Section 1. However, this discussion 
jjs colored by the fact that it illustrates the use of only the most basic kind of looping 
construct. More complex looping constructs support several of the features of series 
expressions. In particular, they allow the equivalent of scanners and collectors (but not 
i ransducers) to be expressed as localized forms rather than as a statements dispersed in 
A loop. 

Most programming languages contain a for construct, which makes it easy to express 

I oops that are based on enumerating a range of integers (i.e., they support a standard 
oop fragment analogous to scan-range). Some languages go beyond this by providing 
pedal looping forms corresponding to a few additional scanners. For example, Common 
jisp provides a form dolist that makes it easy to implement a loop based on scanning 
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the elements of a list. A couple of languages go further still by supporting a relatively 
wid 3 range of standard looping fragments. Some of the oldest and most comprehensive 
sup )ort for this is in Lisp. 

The Lisp Loop macro. The Lisp Loop macro [12] (which is based on the iterative 
statements in the InterLisp Clisp facility [37]) introduces two concepts into Lisp. First, 
it supports a looping construct analogous to for that uses an Algol-like keyword syntax. 
Second, it goes way beyond most for constructs by supporting a wide range of looping 
fragments analogous to scanners and collectors. Because of its non-Lisp syntax, the Loop 
macro has always been controversial. However, because of the utility of its predefined 
looping fragments, it has gained wide use. 

The example below shows a program that uses the Loop macro to implement the 
vector summation algorithm. It also shows how a keyword vector-element (which cor¬ 
responds to scanning a vector) could be defined. (The Loop macro does not support 
the definition of new collector-like fragments.) The code produced by the Loop macro 
is more or less identical to the code produced when optimizable series expressions are 
pipelined. As a result, the two approaches are equally efficient. 

(defun sum-positive-loop-macro (v) 

(loop for item being each vector-element of v 
when (plusp item) 
sum item)) 

(define-loop-path vector-element scan-vector (of)) 

(defun scan-vector (path-name variable data-type prep-phrases 

inclusive? allowed-prepositions data) 

(declare (ignore path-name data-type inclusive? 

allowed-prepositions data)) 

(let ((vector (gensym)) 

(i (gensym)) 

(end (gensym))) 

‘(((.vector) (,i 0) (,end) (,variable)) 

((setq ,vector ,(cadar prep-phrases)) 

(setq .end (- (length ,vector) 1))) 

(> ,i .end) 

(.variable (aref .vector ,i)) 
nil 

(»i (♦ ,i 1))))) 

x>op supports a keyword when that is similar to the transducer choosing (see the 
example). A call on the Loop macro can also contain an arbitrary body that is mapped 
ovei the values computed by the scanner-like fragments (this is not shown in the example). 
Hov ever, the Loop macro does not support any other transducer-like looping fragments. 

. subtle difficulty with the Loop macro is that there are no restrictions on the com¬ 
putation that can be in the body and there is no attempt to prevent the body from 
interfering with the computation specified by the looping fragments. As a result, pro- 
grar imers cannot depend on the fact that these fragments will necessarily do what they 
are ntended to do. 

Another problem with the Loop macro is that the facilities provided for defining the 
equivalent of new scanners are quite cumbersome. The user has to define a procedure that 
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ideals with parsing parts of the Loop syntax and that returns a list of six parts analogous 
to the parts of the loop fragments discussed in Section 6. (Recently, the Common Lisp 
Standardization committee decided to adopt most of the Loop macro as part of Common 
Lisp. However, on the grounds that it is too complex, they decided not to include the 
^canner-defining form.) 

The concept of Generators and Gatherers presented in [29], provides essentially the 
same capabilities as the Loop Macro, but with a more functional syntax and simpler 
defining forms. 

Iterators in CLU. Among Algol-like languages, some of the most powerful support 
for the use of looping fragments is provided by CLU [27]. In CLU, scanner-like fragments 

[ ailed iterators can be used in for loops to generate a series of elements that are processed 
y the body of the for. CLU provides a number of predefined scanners including one 
orresponding to scanning a vector and users can define new ones. (Alphard [49] supports 
construct called a generator that is essentially identical to a CLU iterator.) 

As an illustration, the example below shows how the vector summation algorithm can 

t e expressed in CLU. It also shows the definition of a user-defined scanner. This is done 
y writing a coroutine that yields the scanned elements one at a time. 

SUM.POSITIVE.CLU = proc(V: ARRAY[INT]) returns(INT) 

! SUM: INT :* 0 

for ITEM: INT in SCAN.VECTOR(V) do 

if ITEM>0 then SUM :* SUM+ITEM end 

end 

return(SUM) 
end SUM.POSITIVE.CLU 

SCAN.VECTOR = iter(V: ARRAY[INT]) yields(INT) 

I: INT :* ARRAY[INT]$L0W(V) 

END: INT :* ARRAY[INT]$HIGH(V) 
while I<=END do 
yield(V[I]) 

I := 1+1 
end 

end SCAN.VECTOR 

Taken together, CLU iterators and the for statement are essentially the same as the 
joop macro except for three things. Nothing besides mapping and scanning is supported. 
In the example above, the operations of choosing and summing are both represented in 
ion-local ways in the body of the loop.) Each for can only contain one iterator instead 
of many. CLU’s method for defining iterators as coroutines is significantly easier to use 
han the Loop macro’s scanner-defining form. 

A method for supporting multiple iterators in a CLU for statement is described in 
14]. Going beyond this, [13] describes how one could support collectors (again restricted 
fo only one in each loop). While both of these papers merely present proposals rather 
han describing actual implementations, there is no doubt that everything supported by 
jhe Lisp Loop macro could be straightforwardly supported in an Algol-like language. 

Summary. The key difference between the looping constructs above and series ex¬ 
pressions is that while the looping constructs support looping fragments corresponding to 
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(poi entially unbounded) scanners and collectors and are highly efficient, they do not sup- 
pori the concept of a sequence data structure nor the idea of treating loop fragments as 
procedures. This preserves the iterative feel of the constructs, however, it is significantly 
limiting in several ways. 

The lack of a sequence data type prevents the constructs from supporting anything 
other than a few simple transducers. (It is not clear how one could support transducers 
in general without having some kind of object that they can act upon.) 

The fact that the loop fragments are not procedures means that the way the fragments 
can be used is intimately tied up with the syntax of the constructs. One has to learn a 
new language of combination rather than simply using standard functional composition. 
In c ddition, this new language of combination is much more restricted than functional 
corr position. For instance, the only thing that can be done with a scanner-like fragment 
is to use it in a call on loop or for and map some computation over the values scanned. 

\n interesting thing to note about the looping constructs above is the way they avoid 
getting involved with a discussion of the restrictions in Section 2. By not allowing a 
sequence data structure to be stored in a variable, only supporting preorder fragments, 
largely ignoring transducers (particularly off-line ones), and limiting the way fragments 
can be combined, the constructs implicitly enforce these restrictions without having to 
talk about them. Unfortunately, the total restrictions they embody are much stronger 
tha; 1 the ones in Section 2. This unnecessarily limits what can be expressed. 

8. penefits 

There are three principal perspectives from which to view series expressions. To 
start with, series expressions can be looked at as embodying relatively complete support 
for jequence expressions in such a way that they can be included in any programming 
language without: removing any preexisting features of the language, requiring the use 
of unusual syntax, or causing inefficiency. This support includes most of the operations 
provided by languages such as APL, Lisp, and Seque along with a few additional ones. 

An alternate perspective focuses on the fact that programmers are given clear and 
immediate feedback about the efficiency of the series expressions they write. Series 
expressions that do not violate the restrictions in Section 2 are guaranteed to be as 
efficient as they look. By means of error messages, programmers are encouraged to think 
of e ficient methods for computing the results they want. In particular, unlike APL, Lisp, 
or £ eque, programmers are never tempted to think that all sequence expressions are 
equally efficient. 

A final perspective is summarized by the statement that “optimizable series expres¬ 
sions are to loops as structured control constructs are to gotos.” By using optimizable 
series expressions, it is possible to banish loops from most programs. Given that expres¬ 
sion^ are much easier to understand and modify than loops, this has the potential for 
being a step forward at least as important as banishing gotos. 

Vhile the idea has not yet been explored, optimizable series expressions might also be 
helpful in the context of parallelism. Even though it is optimized for sequential machines, 
the pipelining applied to optimizable series expressions is very much the same as the 
‘software pipelining’ of loops for execution on very large instruction word machines [26] 
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Mid for execution by the processors of a systolic array [2, 20]. If programs were written 
lising series expressions, the process of analyzing the programs to determine a good 
ichedule for the pipelined computation might be simplified. In addition, the restrictions 
jn Section 2 appear relevant, because buffering of elements also causes inefficiency in a 
parallel context. 

The application of optimizable series expressions to non-pipelined parallelism is less 
dear. The emphasis in such situations is on locating opportunities for evaluating sub- 
romputations completely in parallel with no data flow between them. This is appropriate 
or mapping, but not for most of the other series operations. Nevertheless, using opti- 
nizable series expressions might make it easier to detect where such parallelism exists. 
Tor example, this might make it easier to ‘vectorize’ [4] programs. 
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